This is a followup for "[PATCH kernel v4 0/6] vfio-pci: Add support for
mmapping MSI-X table"
http://www.spinics.net/lists/kvm/msg152232.html
This time it is using "caps" in IOMMU groups. The main question is if PCI
bus flags or IOMMU domains are still better (and which one).
Here is some bac
This introduces capabilities to IOMMU groups. The first defined
capability is IOMMU_GROUP_CAP_ISOLATE_MSIX which tells the IOMMU
group users that a particular IOMMU group is capable of MSIX message
filtering; this is useful when deciding whether or not to allow mapping
of MSIX table to the userspac
This sets IOMMU_GROUP_CAP_ISOLATE_MSIX to a group if IRQ remapping
is enabled. For Intel, this checks disable_sourceid_checking in addition;
AMD ignores the "nosid" kernel parameters.
Here is some background on how the isolation works:
On Intel VT-d [1], there is an Interrupt Remapping Table, one
This sets IOMMU_GROUP_CAP_ISOLATE_MSIX to a group if MSI remapping is
enabled on an IRQ domain; this is expected to set the capability
on ARM.
Signed-off-by: Alexey Kardashevskiy
---
drivers/iommu/iommu.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/iommu/iommu.c b/drivers/
This sets IOMMU_GROUP_CAP_ISOLATE_MSIX to a group unconditionally as
there is no IOMMU-capable hardware without such a feature.
On IBM POWERPC (POWER8) [1], PCI host bridge maintains BFDN-to-PE
translation (PE stands for "partitionable endpoint"), and PE index is used
to look at Interrupt Vector T
Hi Robin,
On Fri, Aug 4, 2017 at 10:34 PM, Robin Murphy wrote:
> On 03/08/17 06:35, Vivek Gautam wrote:
>> Hi Robin,
>>
>>
>>
>> On 08/02/2017 05:47 PM, Robin Murphy wrote:
>>> On 02/08/17 10:53, Vivek Gautam wrote:
We don't want to touch the TLB when smmu is suspended.
Defer it until
Some devices have a MSIX BAR not aligned to the system page size
greater than 4K (like 64k for ppc64) which at the moment prevents
such MMIO pages from being mapped to the userspace for the sake of
the MSIX BAR content protection. If such page happens to share
the same system page with some frequen
> -Original Message-
> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: Friday, August 04, 2017 5:57 PM
> To: Shameerali Kolothum Thodi; lorenzo.pieral...@arm.com;
> marc.zyng...@arm.com; sudeep.ho...@arm.com; will.dea...@arm.com;
> hanjun@linaro.org
> Cc: Gabriele Paoloni; Jo
On Thu, Jul 13, 2017 at 5:20 PM, Rob Clark wrote:
> On Thu, Jul 13, 2017 at 1:35 AM, Sricharan R wrote:
>> Hi Vivek,
>>
>> On 7/13/2017 10:43 AM, Vivek Gautam wrote:
>>> Hi Stephen,
>>>
>>>
>>> On 07/13/2017 04:24 AM, Stephen Boyd wrote:
On 07/06, Vivek Gautam wrote:
> @@ -1231,12 +1237,
On 05/08/17 06:14, valmiki wrote:
[...]
> Hi Jean, Thanks a lot, now i understood the flow. From vfio kernel
> documentation we fill vaddr and iova in struct vfio_iommu_type1_dma_map
> and pass them to VFIO. But if we use dynamic allocation in application
> (say malloc), do we need to use dma API t
On 2017/8/7 18:31, Jean-Philippe Brucker wrote:
> On 05/08/17 06:14, valmiki wrote:
> [...]
>> Hi Jean, Thanks a lot, now i understood the flow. From vfio kernel
>> documentation we fill vaddr and iova in struct vfio_iommu_type1_dma_map
>> and pass them to VFIO. But if we use dynamic allocation in
On Mon, Aug 7, 2017 at 4:27 AM, Vivek Gautam
wrote:
> On Thu, Jul 13, 2017 at 5:20 PM, Rob Clark wrote:
>> On Thu, Jul 13, 2017 at 1:35 AM, Sricharan R
>> wrote:
>>> Hi Vivek,
>>>
>>> On 7/13/2017 10:43 AM, Vivek Gautam wrote:
Hi Stephen,
On 07/13/2017 04:24 AM, Stephen Boyd
Hi Bob,
On 07/08/17 13:18, Bob Liu wrote:
> On 2017/8/7 18:31, Jean-Philippe Brucker wrote:
>> On 05/08/17 06:14, valmiki wrote:
>> [...]
>>> Hi Jean, Thanks a lot, now i understood the flow. From vfio kernel
>>> documentation we fill vaddr and iova in struct vfio_iommu_type1_dma_map
>>> and pass
On Mon, Aug 07, 2017 at 08:21:40AM +, Shameerali Kolothum Thodi wrote:
>
>
> > -Original Message-
> > From: Robin Murphy [mailto:robin.mur...@arm.com]
> > Sent: Friday, August 04, 2017 5:57 PM
> > To: Shameerali Kolothum Thodi; lorenzo.pieral...@arm.com;
> > marc.zyng...@arm.com; sude
Hi,
following the official LPC17 VFIO/IOMMU/PCI uconf acceptance notification:
https://www.linuxplumbersconf.org/2017/vfioiommupci-microconference-accepted-into-linux-plumbers-conference/
I am sending out a call for sessions proposals open to all developers
interested/involved in Linux kernel VF
Generalize is_vmd behavior to remove dependency on domain number
checking in pci quirks.
Signed-off-by: Jon Derrick
---
arch/x86/include/asm/pci.h | 8 +++-
arch/x86/pci/common.c | 2 +-
drivers/pci/quirks.c | 2 +-
include/linux/pci.h| 4
4 files changed, 9 insertion
VMD child devices must use the VMD endpoint's ID as the DMA source.
Because of this, there needs to be a way to link the parent VMD
endpoint's DMAR domain to the VMD child devices' DMAR domain such that
attaching and detaching child devices modify the endpoint's DMAR mapping
and prevents early deta
Add myself as VMD maintainer
Signed-off-by: Jon Derrick
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index f66488d..3ec39df 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10090,6 +10090,7 @@ F: drivers/pci/dwc/*imx6*
PCI DRIVER FOR INTEL V
On 2017/8/7 20:52, Jean-Philippe Brucker wrote:
> Hi Bob,
>
> On 07/08/17 13:18, Bob Liu wrote:
>> On 2017/8/7 18:31, Jean-Philippe Brucker wrote:
>>> On 05/08/17 06:14, valmiki wrote:
>>> [...]
Hi Jean, Thanks a lot, now i understood the flow. From vfio kernel
documentation we fill vadd
19 matches
Mail list logo
