Hi Robin,
Thanks for working on this!
On Thu, Mar 17, 2022 at 04:17:07PM +, Robin Murphy wrote:
> Between me trying to get rid of iommu_present() and Mario wanting to
> support the AMD equivalent of DMAR_PLATFORM_OPT_IN, scrutiny has shown
> that the iommu_dma_protection attribute is being fa
> From: Jacob Pan
> Sent: Tuesday, March 15, 2022 1:07 PM
The coverletter is [0/8] but here you actually have the 9th patch...
>
> From: Dave Jiang
>
> The idxd driver always gated the pasid enabling under a single knob and
> this assumption is incorrect. The pasid used for kernel operation c
> From: Jacob Pan
> Sent: Tuesday, March 15, 2022 1:07 PM
>
> In-kernel DMA with PASID should use DMA API now, remove supervisor
> PASID
> SVA support. Remove special cases in bind mm and page request service.
>
> Signed-off-by: Jacob Pan
so you removed all the references to SVM_FLAG_SUPERVISO
> From: Jacob Pan
> Sent: Tuesday, March 15, 2022 1:07 PM
>
> The current in-kernel supervisor PASID support is based on the SVM/SVA
> machinery in SVA lib. The binding between a kernel PASID and kernel
> mapping has many flaws. See discussions in the link below.
>
> This patch enables in-kernel
> -Original Message-
> From: iommu On Behalf Of
> David Stevens
> Sent: Wednesday, March 16, 2022 1:07 PM
> To: Lu Baolu
> Cc: iommu@lists.linux-foundation.org; linux-ker...@vger.kernel.org; David
> Stevens
> Subject: [PATCH] iommu/vt-d: check alignment before using psi
>
> From: Dav
> From: Jason Gunthorpe
> Sent: Thursday, March 17, 2022 8:04 AM
>
> On Wed, Mar 16, 2022 at 10:23:26PM +, Luck, Tony wrote:
>
> > Kernel users (ring0) can supply any PASID when they use
> > the ENQCMDS instruction. Is that what you mean when you
> > say "real applications"?
>
> I'm not tal
> From: Jacob Pan
> Sent: Thursday, March 17, 2022 5:02 AM
>
> Hi Kevin,
>
> On Wed, 16 Mar 2022 07:41:34 +, "Tian, Kevin"
> wrote:
>
> > > From: Jason Gunthorpe
> > > Sent: Tuesday, March 15, 2022 10:33 PM
> > >
> > > On Mon, Mar 14, 2022 at 10:07:07PM -0700, Jacob Pan wrote:
> > > > +
From: Robin Murphy Sent: Thursday, March 17, 2022 10:15
AM
>
> On 2022-03-17 16:25, Michael Kelley via iommu wrote:
> > PCI pass-thru devices in a Hyper-V VM are represented as a VMBus
> > device and as a PCI device. The coherence of the VMbus device is
> > set based on the VMbus node in ACPI,
> From: Jason Gunthorpe
> Sent: Thursday, March 17, 2022 9:53 PM
>
> On Thu, Mar 17, 2022 at 05:47:36AM +, Tian, Kevin wrote:
> > > From: Robin Murphy
> > > Sent: Tuesday, March 15, 2022 6:49 PM
> > >
> > > On 2022-03-14 19:44, Matthew Rosato wrote:
> > > > s390x will introduce an additional
Hi Kevin,
On Wed, 16 Mar 2022 07:54:19 +, "Tian, Kevin"
wrote:
> > From: Jacob Pan
> > Sent: Tuesday, March 15, 2022 1:07 PM
> >
> > With the availability of a generic device-PASID-domain attachment API,
> > there's no need to special case RID2PASID. Use the API to replace
> > duplicated
[Public]
> -Original Message-
> From: Limonciello, Mario
> Sent: Thursday, March 17, 2022 12:09
> To: Robin Murphy ; andreas.noe...@gmail.com;
> michael.ja...@intel.com; mika.westerb...@linux.intel.com;
> yehezkel...@gmail.com
> Cc: linux-...@vger.kernel.org; linux-ker...@vger.kernel.org
From: Robin Murphy Sent: Thursday, March 17, 2022 10:20
AM
>
> On 2022-03-17 16:25, Michael Kelley via iommu wrote:
> > Add a wrapper function to set dma_coherent, avoiding the need for
> > complex #ifdef's when setting it in architecture independent code.
>
> No. It might happen to work out on
From: Robin Murphy Sent: Thursday, March 17, 2022 9:31 AM
>
> On 2022-03-17 16:25, Michael Kelley wrote:
> > Export acpi_get_dma_attr() so that it can be used by the Hyper-V
> > VMbus driver, which may be built as a module. The related function
> > acpi_dma_configure_id() is already exported.
>
On 3/15/22 1:25 PM, Jason Gunthorpe wrote:
On Tue, Mar 15, 2022 at 12:29:02PM -0400, Matthew Rosato wrote:
On 3/15/22 10:38 AM, Jason Gunthorpe wrote:
On Tue, Mar 15, 2022 at 09:49:01AM -0400, Matthew Rosato wrote:
The rationale for splitting steps 1 and 2 are that VFIO_SET_IOMMU doesn't
have
Hi Jason,
On Thu, 17 Mar 2022 10:23:08 -0300, Jason Gunthorpe wrote:
> On Wed, Mar 16, 2022 at 05:49:59PM -0700, Jacob Pan wrote:
>
> > > I would expect real applications will try to use the same PASID for
> > > the same IOVA map to optimize IOTLB caching.
> > >
> > > Is there a use case for t
On 2022-03-17 16:25, Michael Kelley via iommu wrote:
Add a wrapper function to set dma_coherent, avoiding the need for
complex #ifdef's when setting it in architecture independent code.
No. It might happen to work out on the architectures you're looking at,
but if Hyper-V were ever to support,
On 2022-03-17 16:25, Michael Kelley via iommu wrote:
PCI pass-thru devices in a Hyper-V VM are represented as a VMBus
device and as a PCI device. The coherence of the VMbus device is
set based on the VMbus node in ACPI, but the PCI device has no
ACPI node and defaults to not hardware coherent.
[Public]
> -Original Message-
> From: Robin Murphy
> Sent: Thursday, March 17, 2022 11:17
> To: andreas.noe...@gmail.com; michael.ja...@intel.com;
> mika.westerb...@linux.intel.com; yehezkel...@gmail.com
> Cc: linux-...@vger.kernel.org; linux-ker...@vger.kernel.org;
> iommu@lists.linux-
On Thu, Mar 17, 2022 at 04:17:07PM +, Robin Murphy wrote:
> Between me trying to get rid of iommu_present() and Mario wanting to
> support the AMD equivalent of DMAR_PLATFORM_OPT_IN, scrutiny has shown
> that the iommu_dma_protection attribute is being far too optimistic.
> Even if an IOMMU mig
On 2022-03-17 16:25, Michael Kelley via iommu wrote:
VMbus synthetic devices are not represented in the ACPI DSDT -- only
the top level VMbus device is represented. As a result, on ARM64
coherence information in the _CCA method is not specified for
synthetic devices, so they default to not hardwa
On 2022-03-17 16:25, Michael Kelley wrote:
Export acpi_get_dma_attr() so that it can be used by the Hyper-V
VMbus driver, which may be built as a module. The related function
acpi_dma_configure_id() is already exported.
No. Use device_get_dma_attr() like everyone else, please.
Robin.
Signed-
VMbus synthetic devices are not represented in the ACPI DSDT -- only
the top level VMbus device is represented. As a result, on ARM64
coherence information in the _CCA method is not specified for
synthetic devices, so they default to not hardware coherent.
Drivers for some of these synthetic device
PCI pass-thru devices in a Hyper-V VM are represented as a VMBus
device and as a PCI device. The coherence of the VMbus device is
set based on the VMbus node in ACPI, but the PCI device has no
ACPI node and defaults to not hardware coherent. This results
in extra software coherence management ove
Export acpi_get_dma_attr() so that it can be used by the Hyper-V
VMbus driver, which may be built as a module. The related function
acpi_dma_configure_id() is already exported.
Signed-off-by: Michael Kelley
---
drivers/acpi/scan.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/acpi/
Add a wrapper function to set dma_coherent, avoiding the need for
complex #ifdef's when setting it in architecture independent code.
Signed-off-by: Michael Kelley
---
include/linux/dma-map-ops.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/include/linux/dma-map-ops.h b/include/li
[Resend to fix an email address typo for Bjorn Helgaas]
Hyper-V VMs have VMbus synthetic devices and PCI pass-thru devices that are
added
dynamically via the VMbus protocol and are not represented in the ACPI DSDT.
Only
the top level VMbus node exists in the DSDT. As such, on ARM64 these devices
Between me trying to get rid of iommu_present() and Mario wanting to
support the AMD equivalent of DMAR_PLATFORM_OPT_IN, scrutiny has shown
that the iommu_dma_protection attribute is being far too optimistic.
Even if an IOMMU might be present for some PCI segment in the system,
that doesn't necessa
Add a wrapper function to set dma_coherent, avoiding the need for
complex #ifdef's when setting it in architecture independent code.
Signed-off-by: Michael Kelley
---
include/linux/dma-map-ops.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/include/linux/dma-map-ops.h b/include/li
PCI pass-thru devices in a Hyper-V VM are represented as a VMBus
device and as a PCI device. The coherence of the VMbus device is
set based on the VMbus node in ACPI, but the PCI device has no
ACPI node and defaults to not hardware coherent. This results
in extra software coherence management ove
Export acpi_get_dma_attr() so that it can be used by the Hyper-V
VMbus driver, which may be built as a module. The related function
acpi_dma_configure_id() is already exported.
Signed-off-by: Michael Kelley
---
drivers/acpi/scan.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/acpi/
Hyper-V VMs have VMbus synthetic devices and PCI pass-thru devices that are
added
dynamically via the VMbus protocol and are not represented in the ACPI DSDT.
Only
the top level VMbus node exists in the DSDT. As such, on ARM64 these devices
don't
pick up coherence information and default to not
VMbus synthetic devices are not represented in the ACPI DSDT -- only
the top level VMbus device is represented. As a result, on ARM64
coherence information in the _CCA method is not specified for
synthetic devices, so they default to not hardware coherent.
Drivers for some of these synthetic device
> -Original Message-
> From: Eric Auger [mailto:eric.au...@redhat.com]
> Sent: 15 March 2022 17:53
> To: Shameerali Kolothum Thodi ;
> linux-arm-ker...@lists.infradead.org; linux-a...@vger.kernel.org;
> iommu@lists.linux-foundation.org
> Cc: Linuxarm ; lorenzo.pieral...@arm.com;
> j...@8
Hi Robin,
On Thu, Mar 17, 2022 at 01:42:56PM +, Robin Murphy wrote:
> On 2022-03-17 08:08, Mika Westerberg wrote:
> > Hi Robin,
> >
> > On Wed, Mar 16, 2022 at 07:17:57PM +, Robin Murphy wrote:
> > > The feeling I'm getting from all this is that if we've got as far as
> > > iommu_dma_prot
On Thu, Mar 17, 2022 at 05:47:36AM +, Tian, Kevin wrote:
> > From: Robin Murphy
> > Sent: Tuesday, March 15, 2022 6:49 PM
> >
> > On 2022-03-14 19:44, Matthew Rosato wrote:
> > > s390x will introduce an additional domain type that is used for
> > > managing IOMMU owned by KVM. Define the type
On 2022-03-17 08:08, Mika Westerberg wrote:
Hi Robin,
On Wed, Mar 16, 2022 at 07:17:57PM +, Robin Murphy wrote:
The feeling I'm getting from all this is that if we've got as far as
iommu_dma_protection_show() then it's really too late to meaningfully
mitigate bad firmware.
Note, these are
On Wed, Mar 16, 2022 at 05:49:59PM -0700, Jacob Pan wrote:
> > I would expect real applications will try to use the same PASID for
> > the same IOVA map to optimize IOTLB caching.
> >
> > Is there a use case for that I'm missing?
> >
> Yes. it would be more efficient for PASID selective domain T
Hi Robin,
On Wed, Mar 16, 2022 at 07:17:57PM +, Robin Murphy wrote:
> The feeling I'm getting from all this is that if we've got as far as
> iommu_dma_protection_show() then it's really too late to meaningfully
> mitigate bad firmware.
Note, these are requirements from Microsoft in order for
38 matches
Mail list logo
