> From: Jason Gunthorpe
> Sent: Thursday, March 24, 2022 4:34 AM
>
> On Wed, Mar 23, 2022 at 02:04:46PM -0600, Alex Williamson wrote:
> > On Wed, 23 Mar 2022 16:34:39 -0300
> > Jason Gunthorpe wrote:
> >
> > > On Wed, Mar 23, 2022 at 01:10:38PM -0600, Alex Williamson wrote:
> > > > On Fri, 18 Ma
On Wed, Mar 23, 2022 at 08:54:08PM +, Robin Murphy wrote:
> I'll admit I still never quite grasped the reason for also adding the
> override to swiotlb_sync_single_for_device() in aa6f8dcbab47, but I think
> by that point we were increasingly tired and confused and starting to
> second-guess
> From: Jason Wang
> Sent: Thursday, March 24, 2022 11:51 AM
>
> > >
> >
> > In the end vfio type1 will be replaced by iommufd compat layer. With
> > that goal in mind iommufd has to inherit type1 behaviors.
>
> So the compatibility should be provided by the compat layer instead of
> the core io
On Thu, Mar 24, 2022 at 11:15 AM Tian, Kevin wrote:
>
> > From: Jason Wang
> > Sent: Thursday, March 24, 2022 10:57 AM
> >
> > On Thu, Mar 24, 2022 at 10:42 AM Tian, Kevin wrote:
> > >
> > > > From: Jason Wang
> > > > Sent: Thursday, March 24, 2022 10:28 AM
> > > >
> > > > On Thu, Mar 24, 2022
> From: Jason Wang
> Sent: Thursday, March 24, 2022 10:57 AM
>
> On Thu, Mar 24, 2022 at 10:42 AM Tian, Kevin wrote:
> >
> > > From: Jason Wang
> > > Sent: Thursday, March 24, 2022 10:28 AM
> > >
> > > On Thu, Mar 24, 2022 at 10:12 AM Tian, Kevin
> wrote:
> > > >
> > > > > From: Jason Gunthorp
> From: Jason Gunthorpe
> Sent: Thursday, March 24, 2022 2:16 AM
>
> On Tue, Mar 22, 2022 at 04:15:44PM -0600, Alex Williamson wrote:
>
> > > +int iopt_access_pages(struct io_pagetable *iopt, unsigned long iova,
> > > + unsigned long length, struct page **out_pages, bool write)
> >
On Wed, Mar 23, 2022 at 07:55:23PM -0500, Rob Herring wrote:
> On Wed, Mar 23, 2022 at 5:15 PM dann frazier
> wrote:
> >
> > On Wed, Mar 23, 2022 at 09:49:04AM +, Marc Zyngier wrote:
> > > On Tue, 22 Mar 2022 17:27:36 +,
> > > Robin Murphy wrote:
> > > >
> > > > Originally, creating the
On Thu, Mar 24, 2022 at 10:42 AM Tian, Kevin wrote:
>
> > From: Jason Wang
> > Sent: Thursday, March 24, 2022 10:28 AM
> >
> > On Thu, Mar 24, 2022 at 10:12 AM Tian, Kevin wrote:
> > >
> > > > From: Jason Gunthorpe
> > > > Sent: Wednesday, March 23, 2022 12:15 AM
> > > >
> > > > On Tue, Mar 22,
> From: Jason Wang
> Sent: Thursday, March 24, 2022 10:28 AM
>
> On Thu, Mar 24, 2022 at 10:12 AM Tian, Kevin wrote:
> >
> > > From: Jason Gunthorpe
> > > Sent: Wednesday, March 23, 2022 12:15 AM
> > >
> > > On Tue, Mar 22, 2022 at 09:29:23AM -0600, Alex Williamson wrote:
> > >
> > > > I'm stil
On Thu, Mar 24, 2022 at 10:12 AM Tian, Kevin wrote:
>
> > From: Jason Gunthorpe
> > Sent: Wednesday, March 23, 2022 12:15 AM
> >
> > On Tue, Mar 22, 2022 at 09:29:23AM -0600, Alex Williamson wrote:
> >
> > > I'm still picking my way through the series, but the later compat
> > > interface doesn't
> From: Jason Gunthorpe
> Sent: Wednesday, March 23, 2022 12:15 AM
>
> On Tue, Mar 22, 2022 at 09:29:23AM -0600, Alex Williamson wrote:
>
> > I'm still picking my way through the series, but the later compat
> > interface doesn't mention this difference as an outstanding issue.
> > Doesn't this
On Wed, Mar 23, 2022 at 01:31:12PM -0700, Michael Kelley 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 har
On Tue, Mar 22, 2022 at 12:27 PM Robin Murphy wrote:
>
> Originally, creating the dma_ranges resource list in pre-sorted fashion
> was the simplest and most efficient way to enforce the order required by
> iova_reserve_pci_windows(). However since then at least one PCI host
> driver is now re-sort
On Wed, Mar 23, 2022 at 5:15 PM dann frazier wrote:
>
> On Wed, Mar 23, 2022 at 09:49:04AM +, Marc Zyngier wrote:
> > On Tue, 22 Mar 2022 17:27:36 +,
> > Robin Murphy wrote:
> > >
> > > Originally, creating the dma_ranges resource list in pre-sorted fashion
> > > was the simplest and most
On Wed, Mar 23, 2022 at 04:51:25PM -0600, Alex Williamson wrote:
> My overall question here would be whether we can actually achieve a
> compatibility interface that has sufficient feature transparency that we
> can dump vfio code in favor of this interface, or will there be enough
> niche use cas
On Wed, Mar 23, 2022 at 05:34:18PM -0300, Jason Gunthorpe wrote:
> Stated another way, any platform that wires dev_is_dma_coherent() to
> true, like all x86 does, must support IOMMU_CACHE and report
> IOMMU_CAP_CACHE_COHERENCY for every iommu_domain the platform
> supports. The platform obviously
On Fri, 18 Mar 2022 14:27:36 -0300
Jason Gunthorpe wrote:
> iommufd can directly implement the /dev/vfio/vfio container IOCTLs by
> mapping them into io_pagetable operations. Doing so allows the use of
> iommufd by symliking /dev/vfio/vfio to /dev/iommufd. Allowing VFIO to
> SET_CONTAINER using a
On Wed, Mar 23, 2022 at 09:49:04AM +, Marc Zyngier wrote:
> On Tue, 22 Mar 2022 17:27:36 +,
> Robin Murphy wrote:
> >
> > Originally, creating the dma_ranges resource list in pre-sorted fashion
> > was the simplest and most efficient way to enforce the order required by
> > iova_reserve_p
On 2022-03-23 19:16, Linus Torvalds wrote:
On Wed, Mar 23, 2022 at 12:06 PM Robin Murphy wrote:
On 2022-03-23 17:27, Linus Torvalds wrote:
I'm assuming that the ath9k issue is that it gives DMA mapping a big
enough area to handle any possible packet size, and just expects -
quite reasonably
On Wed, Mar 23, 2022 at 02:04:46PM -0600, Alex Williamson wrote:
> On Wed, 23 Mar 2022 16:34:39 -0300
> Jason Gunthorpe wrote:
>
> > On Wed, Mar 23, 2022 at 01:10:38PM -0600, Alex Williamson wrote:
> > > On Fri, 18 Mar 2022 14:27:33 -0300
> > > Jason Gunthorpe wrote:
> > >
> > > > +static int
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
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
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
On Wed, 23 Mar 2022 16:34:39 -0300
Jason Gunthorpe wrote:
> On Wed, Mar 23, 2022 at 01:10:38PM -0600, Alex Williamson wrote:
> > On Fri, 18 Mar 2022 14:27:33 -0300
> > Jason Gunthorpe wrote:
> >
> > > +static int conv_iommu_prot(u32 map_flags)
> > > +{
> > > + int iommu_prot;
> > > +
> > > +
On Wed, Mar 23, 2022 at 01:10:38PM -0600, Alex Williamson wrote:
> On Fri, 18 Mar 2022 14:27:33 -0300
> Jason Gunthorpe wrote:
>
> > +static int conv_iommu_prot(u32 map_flags)
> > +{
> > + int iommu_prot;
> > +
> > + /*
> > +* We provide no manual cache coherency ioctls to userspace and m
On Wed, Mar 23, 2022 at 12:06 PM Robin Murphy wrote:
>
> On 2022-03-23 17:27, Linus Torvalds wrote:
> >
> > I'm assuming that the ath9k issue is that it gives DMA mapping a big
> > enough area to handle any possible packet size, and just expects -
> > quite reasonably - smaller packets to only fil
On Fri, 18 Mar 2022 14:27:33 -0300
Jason Gunthorpe wrote:
> +static int conv_iommu_prot(u32 map_flags)
> +{
> + int iommu_prot;
> +
> + /*
> + * We provide no manual cache coherency ioctls to userspace and most
> + * architectures make the CPU ops for cache flushing privileged.
On 2022-03-23 17:27, Linus Torvalds wrote:
On Wed, Mar 23, 2022 at 12:19 AM Oleksandr Natalenko
wrote:
The following upstream commits:
aa6f8dcbab47 swiotlb: rework "fix info leak with DMA_FROM_DEVICE"
ddbd89deb7d3 swiotlb: fix info leak with DMA_FROM_DEVICE
break ath9k-based Wi-Fi access poi
On Tue, Mar 22, 2022 at 04:15:44PM -0600, Alex Williamson wrote:
> > +static struct iopt_area *
> > +iopt_alloc_area(struct io_pagetable *iopt, struct iopt_pages *pages,
> > + unsigned long iova, unsigned long start_byte,
> > + unsigned long length, int iommu_prot, unsigned int
On Wed, Mar 23, 2022 at 12:10:01PM -0600, Alex Williamson wrote:
> > +EXPORT_SYMBOL_GPL(iommufd_bind_pci_device);
>
> I'm stumped why this needs to be PCI specific. Anything beyond the RID
> comment? Please enlighten. Thanks,
The way it turned out in the end it is not for a good reason any
mor
On Fri, 18 Mar 2022 14:27:35 -0300
Jason Gunthorpe wrote:
> +/**
> + * iommufd_bind_pci_device - Bind a physical device to an iommu fd
> + * @fd: iommufd file descriptor.
> + * @pdev: Pointer to a physical PCI device struct
> + * @id: Output ID number to return to userspace for this device
> + *
>
On Wed, Mar 23, 2022 at 12:19 AM Oleksandr Natalenko
wrote:
>
> The following upstream commits:
>
> aa6f8dcbab47 swiotlb: rework "fix info leak with DMA_FROM_DEVICE"
> ddbd89deb7d3 swiotlb: fix info leak with DMA_FROM_DEVICE
>
> break ath9k-based Wi-Fi access point for me. The AP emits beacons, bu
On Wed, Mar 23, 2022 at 04:37:50PM +0100, Niklas Schnelle wrote:
> > +/*
> > + * This holds a pinned page list for multiple areas of IO address space.
> > The
> > + * pages always originate from a linear chunk of userspace VA. Multiple
> > + * io_pagetable's, through their iopt_area's, can share a
> -Original Message-
> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: 22 March 2022 19:09
> To: Shameerali Kolothum Thodi ;
> linux-arm-ker...@lists.infradead.org; linux-a...@vger.kernel.org;
> iommu@lists.linux-foundation.org
> Cc: j...@solid-run.com; Linuxarm ;
> steven.pr...
> -Original Message-
> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: 22 March 2022 18:27
> 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...@
On Fri, 2022-03-18 at 14:27 -0300, Jason Gunthorpe wrote:
> The top of the data structure provides an IO Address Space (IOAS) that is
> similar to a VFIO container. The IOAS allows map/unmap of memory into
> ranges of IOVA called iopt_areas. Domains and in-kernel users (like VFIO
> mdevs) can be at
> On 23 Mar 2022, at 12:40, Robin Murphy wrote:
>
> On 2022-03-23 12:54, Miguel Luis wrote:
>> Allows userspace to check for SMMUv3 features.
>
> What will userspace do with that information?
>
> It hardly matters what fancy new features might be present, if the kernel
> and/or the abstracte
On 2022-03-23 12:54, Miguel Luis wrote:
Allows userspace to check for SMMUv3 features.
What will userspace do with that information?
It hardly matters what fancy new features might be present, if the
kernel and/or the abstracted interfaces available to userspace aren't
using them. Any functi
Allows userspace to check for SMMUv3 features.
Expose the following RO registers related to ARM SMMUv3 via sysfs:
SMMU_IDR0
SMMU_IDR1
SMMU_IDR2
SMMU_IDR3
SMMU_IDR4
SMMU_IDR5
SMMU_IDR6
SMMU_IIDR
SMMU_AIDR
# find /sys | grep arm-iommu
/sys/devices/platform/905.smmuv3/iommu/smmu3.0x0905
Adding regressions list so that this can be tracked properly, including
the full report below.
Oleksandr Natalenko writes:
> Hello.
>
> The following upstream commits:
>
> aa6f8dcbab47 swiotlb: rework "fix info leak with DMA_FROM_DEVICE"
> ddbd89deb7d3 swiotlb: fix info leak with DMA_FROM_DEVICE
Hello.
The following upstream commits:
aa6f8dcbab47 swiotlb: rework "fix info leak with DMA_FROM_DEVICE"
ddbd89deb7d3 swiotlb: fix info leak with DMA_FROM_DEVICE
break ath9k-based Wi-Fi access point for me. The AP emits beacons, but no
client can connect to it, either from the very beginning, o
On Tue, 22 Mar 2022 17:27:36 +,
Robin Murphy wrote:
>
> Originally, creating the dma_ranges resource list in pre-sorted fashion
> was the simplest and most efficient way to enforce the order required by
> iova_reserve_pci_windows(). However since then at least one PCI host
> driver is now re-
42 matches
Mail list logo
