Re: [PATCH V5 12/12] net: netvsc: Add Isolation VM support for netvsc driver

2021-09-29 Thread Christoph Hellwig
On Tue, Sep 28, 2021 at 05:23:31PM +0800, Tianyu Lan wrote: >> >> - the bare memremap usage in swiotlb looks strange and I'd >> definitively expect a well documented wrapper. > > OK. Should the wrapper in the DMA code? How about dma_map_decrypted() > introduced in the V4? A mentioned then

Re: [PATCH 1/2] dma-mapping: remove bogus test for pfn_valid from dma_map_resource

2021-09-29 Thread Christoph Hellwig
On Thu, Sep 30, 2021 at 04:30:38AM +0300, Mike Rapoport wrote: > From: Mike Rapoport > > dma_map_resource() uses pfn_valid() to ensure the range is not RAM. > However, pfn_valid() only checks for availability of the memory map for a > PFN but it does not ensure that the PFN is actually backed by

Re: [PATCH kernel] powerpc/iommu: Report the correct most efficient DMA mask for PCI devices

2021-09-29 Thread Christoph Hellwig
On Thu, Sep 30, 2021 at 01:44:54PM +1000, Alexey Kardashevskiy wrote: > and returns the IOMMU table mask on the pseries platform which makes some > drivers (mpt3sas is one example) choose 32bit DMA even though bypass is > supported. The powernv platform sort of handles it by having a bigger >

Re: [PATCH RFC v1 01/11] uapi/virtio-iommu: Add page request grp-id and flags information

2021-09-29 Thread Vivek Kumar Gautam
Hi Jean, On 9/21/21 9:28 PM, Jean-Philippe Brucker wrote: Hi Vivek, Thanks a lot for your work on this Thanks a lot for taking a look at it. I hope that most of the changes in this series and the nested page table series [1] are independent of the presently on-going /dev/iommu proposal,

Re: [RFC 06/20] iommu: Add iommu_device_init[exit]_user_dma interfaces

2021-09-29 Thread David Gibson
On Wed, Sep 29, 2021 at 07:31:08AM +, Tian, Kevin wrote: > > From: David Gibson > > Sent: Wednesday, September 29, 2021 2:35 PM > > > > On Wed, Sep 29, 2021 at 05:38:56AM +, Tian, Kevin wrote: > > > > From: David Gibson > > > > Sent: Wednesday, September 29, 2021 12:56 PM > > > > > > > >

Re: [RFC 06/20] iommu: Add iommu_device_init[exit]_user_dma interfaces

2021-09-29 Thread David Gibson
On Wed, Sep 29, 2021 at 09:57:16AM -0300, Jason Gunthorpe wrote: > On Wed, Sep 29, 2021 at 04:35:19PM +1000, David Gibson wrote: > > > Yes, exactly. And with a group interface it's obvious it has to > > understand it. With the non-group interface, you can get to this > > stage in ignorance of

Re: [RFC 07/20] iommu/iommufd: Add iommufd_[un]bind_device()

2021-09-29 Thread David Gibson
On Wed, Sep 29, 2021 at 09:24:57AM -0300, Jason Gunthorpe wrote: 65;6402;1c> On Wed, Sep 29, 2021 at 03:25:54PM +1000, David Gibson wrote: > > > > +struct iommufd_device { > > > + unsigned int id; > > > + struct iommufd_ctx *ictx; > > > + struct device *dev; /* always be the physical device */ >

Re: [RFC 08/20] vfio/pci: Add VFIO_DEVICE_BIND_IOMMUFD

2021-09-29 Thread David Gibson
On Wed, Sep 29, 2021 at 06:41:00AM +, Tian, Kevin wrote: > > From: David Gibson > > Sent: Wednesday, September 29, 2021 2:01 PM > > > > On Sun, Sep 19, 2021 at 02:38:36PM +0800, Liu Yi L wrote: > > > This patch adds VFIO_DEVICE_BIND_IOMMUFD for userspace to bind the > > vfio > > > device to

[PATCH kernel] powerpc/iommu: Report the correct most efficient DMA mask for PCI devices

2021-09-29 Thread Alexey Kardashevskiy
According to dma-api.rst, the dma_get_required_mask() helper should return "the mask that the platform requires to operate efficiently". Which in the case of PPC64 means the bypass mask and not a mask from an IOMMU table which is shorter and slower to use due to map/unmap operations (especially

Re: [PATCH v8 09/12] media: mtk-vcodec: Get rid of mtk_smi_larb_get/put

2021-09-29 Thread Yong Wu
Hi Dafna, Thanks very much for the review. On Wed, 2021-09-29 at 14:13 +0200, Dafna Hirschfeld wrote: > > On 29.09.21 03:37, Yong Wu wrote: > > MediaTek IOMMU has already added the device_link between the > > consumer > > and smi-larb device. If the vcodec device call the > >

Re: [RFC 03/20] vfio: Add vfio_[un]register_device()

2021-09-29 Thread da...@gibson.dropbear.id.au
On Wed, Sep 29, 2021 at 09:22:30AM -0300, Jason Gunthorpe wrote: > On Wed, Sep 29, 2021 at 12:46:14PM +1000, da...@gibson.dropbear.id.au wrote: > > On Tue, Sep 21, 2021 at 10:00:14PM -0300, Jason Gunthorpe wrote: > > > On Wed, Sep 22, 2021 at 12:54:02AM +, Tian, Kevin wrote: > > > > > From:

Re: [RFC 02/20] vfio: Add device class for /dev/vfio/devices

2021-09-29 Thread David Gibson
On Wed, Sep 29, 2021 at 01:05:21PM -0600, Alex Williamson wrote: > On Wed, 29 Sep 2021 12:08:59 +1000 > David Gibson wrote: > > > On Sun, Sep 19, 2021 at 02:38:30PM +0800, Liu Yi L wrote: > > > This patch introduces a new interface (/dev/vfio/devices/$DEVICE) for > > > userspace to directly open

[PATCH 2/2] arm64/mm: drop HAVE_ARCH_PFN_VALID

2021-09-29 Thread Mike Rapoport
From: Anshuman Khandual CONFIG_SPARSEMEM_VMEMMAP is now the only available memory model on arm64 platforms and free_unused_memmap() would just return without creating any holes in the memmap mapping. There is no need for any special handling in pfn_valid() and HAVE_ARCH_PFN_VALID can just be

[PATCH 1/2] dma-mapping: remove bogus test for pfn_valid from dma_map_resource

2021-09-29 Thread Mike Rapoport
From: Mike Rapoport dma_map_resource() uses pfn_valid() to ensure the range is not RAM. However, pfn_valid() only checks for availability of the memory map for a PFN but it does not ensure that the PFN is actually backed by RAM. As dma_map_resource() is the only method in DMA mapping APIs that

[PATCH 0/2] arm64: retry dropping HAVE_ARCH_PFN_VALID

2021-09-29 Thread Mike Rapoport
From: Mike Rapoport Hi, This is a new attempt to drop HAVE_ARCH_PFN_VALID on arm64 and start using the generic implementation of pfn_valid(). The first patch removes the check for pfn_valid() in dma_map_resource() which is required to avoid false positives when there is memory map for MMIO.

Re: [PATCH 5/8] x86/mmu: Add mm-based PASID refcounting

2021-09-29 Thread Fenghua Yu
Hi, Baolu, On Thu, Sep 23, 2021 at 01:43:32PM +0800, Lu Baolu wrote: > On 9/21/21 3:23 AM, Fenghua Yu wrote: > > +void pasid_put(struct task_struct *tsk, struct mm_struct *mm) > > +{ > > + if (!cpu_feature_enabled(X86_FEATURE_ENQCMD)) > > + return; > > + > > + /* > > +* Nothing

Re: [PATCH 1/8] iommu/vt-d: Clean up unused PASID updating functions

2021-09-29 Thread Fenghua Yu
Hi, Baolu, On Wed, Sep 29, 2021 at 03:34:51PM +0800, Lu Baolu wrote: > On 2021/9/21 3:23, Fenghua Yu wrote: > > update_pasid() and its call chain are currently unused in the tree because > > Thomas disabled the ENQCMD feature. The feature will be re-enabled shortly > > using a different approach

Re: [PATCH v3 19/20] PCI/P2PDMA: introduce pci_mmap_p2pmem()

2021-09-29 Thread Jason Gunthorpe
On Wed, Sep 29, 2021 at 05:49:36PM -0600, Logan Gunthorpe wrote: > Some of this seems out of date. Pretty sure the pages are not refcounted > with vmf_insert_mixed() and vmf_insert_mixed() is currently the only way > to use VM_MIXEDMAP mappings. Hum. vmf_insert_mixed() boils down to

Re: [PATCH v3 00/20] Userspace P2PDMA with O_DIRECT NVMe devices

2021-09-29 Thread Logan Gunthorpe
On 2021-09-29 5:36 p.m., Jason Gunthorpe wrote: > On Wed, Sep 29, 2021 at 05:28:38PM -0600, Logan Gunthorpe wrote: >> >> >> On 2021-09-29 5:21 p.m., Jason Gunthorpe wrote: >>> On Wed, Sep 29, 2021 at 03:50:02PM -0600, Logan Gunthorpe wrote: On 2021-09-28 2:02 p.m., Jason

Re: [PATCH v3 19/20] PCI/P2PDMA: introduce pci_mmap_p2pmem()

2021-09-29 Thread Logan Gunthorpe
On 2021-09-29 5:35 p.m., Jason Gunthorpe wrote: > On Wed, Sep 29, 2021 at 05:27:22PM -0600, Logan Gunthorpe wrote: > >>> finish_fault() should set the pte_devmap - eg by passing the >>> PFN_DEV|PFN_MAP somehow through the vma->vm_page_prot to mk_pte() or >>> otherwise signaling do_set_pte()

Re: [RFC 0/7] Support in-kernel DMA with PASID and SVA

2021-09-29 Thread Jason Gunthorpe via iommu
On Wed, Sep 29, 2021 at 03:57:20PM -0700, Jacob Pan wrote: > Hi Jason, > > On Wed, 29 Sep 2021 16:39:53 -0300, Jason Gunthorpe wrote: > > > On Wed, Sep 29, 2021 at 12:37:19PM -0700, Jacob Pan wrote: > > > > > For #2, it seems we can store the kernel PASID in struct device. This > > > will

Re: [PATCH v3 4/20] PCI/P2PDMA: introduce helpers for dma_map_sg implementations

2021-09-29 Thread Jason Gunthorpe via iommu
On Wed, Sep 29, 2021 at 05:00:43PM -0600, Logan Gunthorpe wrote: > > > > On 2021-09-29 4:46 p.m., Jason Gunthorpe wrote: > > On Wed, Sep 29, 2021 at 03:30:42PM -0600, Logan Gunthorpe wrote: > >> On 2021-09-28 4:05 p.m., Jason Gunthorpe wrote: > >> No, that's not a correct reading of the code.

Re: [PATCH v3 00/20] Userspace P2PDMA with O_DIRECT NVMe devices

2021-09-29 Thread Jason Gunthorpe
On Wed, Sep 29, 2021 at 05:28:38PM -0600, Logan Gunthorpe wrote: > > > On 2021-09-29 5:21 p.m., Jason Gunthorpe wrote: > > On Wed, Sep 29, 2021 at 03:50:02PM -0600, Logan Gunthorpe wrote: > >> > >> > >> On 2021-09-28 2:02 p.m., Jason Gunthorpe wrote: > >>> On Thu, Sep 16, 2021 at 05:40:40PM

Re: [PATCH v3 19/20] PCI/P2PDMA: introduce pci_mmap_p2pmem()

2021-09-29 Thread Jason Gunthorpe
On Wed, Sep 29, 2021 at 05:27:22PM -0600, Logan Gunthorpe wrote: > > finish_fault() should set the pte_devmap - eg by passing the > > PFN_DEV|PFN_MAP somehow through the vma->vm_page_prot to mk_pte() or > > otherwise signaling do_set_pte() that it should set those PTE bits > > when it creates the

Re: [PATCH v3 00/20] Userspace P2PDMA with O_DIRECT NVMe devices

2021-09-29 Thread Logan Gunthorpe
On 2021-09-29 5:21 p.m., Jason Gunthorpe wrote: > On Wed, Sep 29, 2021 at 03:50:02PM -0600, Logan Gunthorpe wrote: >> >> >> On 2021-09-28 2:02 p.m., Jason Gunthorpe wrote: >>> On Thu, Sep 16, 2021 at 05:40:40PM -0600, Logan Gunthorpe wrote: Hi, This patchset continues my work to

Re: [PATCH v3 19/20] PCI/P2PDMA: introduce pci_mmap_p2pmem()

2021-09-29 Thread Logan Gunthorpe
On 2021-09-29 5:05 p.m., Jason Gunthorpe wrote: > On Wed, Sep 29, 2021 at 03:42:00PM -0600, Logan Gunthorpe wrote: > >> The main reason is probably this: if we don't use VM_MIXEDMAP, then we >> can't set pte_devmap(). > > I think that is an API limitation in the fault routines.. > >

Re: [PATCH v3 00/20] Userspace P2PDMA with O_DIRECT NVMe devices

2021-09-29 Thread Jason Gunthorpe
On Wed, Sep 29, 2021 at 03:50:02PM -0600, Logan Gunthorpe wrote: > > > On 2021-09-28 2:02 p.m., Jason Gunthorpe wrote: > > On Thu, Sep 16, 2021 at 05:40:40PM -0600, Logan Gunthorpe wrote: > >> Hi, > >> > >> This patchset continues my work to add userspace P2PDMA access using > >> O_DIRECT NVMe

Re: [PATCH v3 19/20] PCI/P2PDMA: introduce pci_mmap_p2pmem()

2021-09-29 Thread Jason Gunthorpe
On Wed, Sep 29, 2021 at 03:42:00PM -0600, Logan Gunthorpe wrote: > The main reason is probably this: if we don't use VM_MIXEDMAP, then we > can't set pte_devmap(). I think that is an API limitation in the fault routines.. finish_fault() should set the pte_devmap - eg by passing the

Re: [PATCH v3 4/20] PCI/P2PDMA: introduce helpers for dma_map_sg implementations

2021-09-29 Thread Logan Gunthorpe
On 2021-09-29 4:46 p.m., Jason Gunthorpe wrote: > On Wed, Sep 29, 2021 at 03:30:42PM -0600, Logan Gunthorpe wrote: >> On 2021-09-28 4:05 p.m., Jason Gunthorpe wrote: >> No, that's not a correct reading of the code. Every time there is a new >> pagemap, this code calculates the mapping type and

Re: [PATCH v3 12/20] RDMA/rw: use dma_map_sgtable()

2021-09-29 Thread Logan Gunthorpe
On 2021-09-28 1:43 p.m., Jason Gunthorpe wrote: > On Thu, Sep 16, 2021 at 05:40:52PM -0600, Logan Gunthorpe wrote: >> dma_map_sg() now supports the use of P2PDMA pages so pci_p2pdma_map_sg() >> is no longer necessary and may be dropped. >> >> Switch to the dma_map_sgtable() interface which

Re: [RFC 0/7] Support in-kernel DMA with PASID and SVA

2021-09-29 Thread Jacob Pan
Hi Jason, On Wed, 29 Sep 2021 16:39:53 -0300, Jason Gunthorpe wrote: > On Wed, Sep 29, 2021 at 12:37:19PM -0700, Jacob Pan wrote: > > > For #2, it seems we can store the kernel PASID in struct device. This > > will preserve the DMA API interface while making it PASID capable. > > Essentially,

Re: [PATCH v3 14/20] mm: introduce FOLL_PCI_P2PDMA to gate getting PCI P2PDMA pages

2021-09-29 Thread Jason Gunthorpe
On Wed, Sep 29, 2021 at 03:34:22PM -0600, Logan Gunthorpe wrote: > > > > On 2021-09-28 1:47 p.m., Jason Gunthorpe wrote: > > On Thu, Sep 16, 2021 at 05:40:54PM -0600, Logan Gunthorpe wrote: > >> Callers that expect PCI P2PDMA pages can now set FOLL_PCI_P2PDMA to > >> allow obtaining P2PDMA

Re: [PATCH v3 4/20] PCI/P2PDMA: introduce helpers for dma_map_sg implementations

2021-09-29 Thread Jason Gunthorpe via iommu
On Wed, Sep 29, 2021 at 03:30:42PM -0600, Logan Gunthorpe wrote: > > > > On 2021-09-28 4:05 p.m., Jason Gunthorpe wrote: > > On Thu, Sep 16, 2021 at 05:40:44PM -0600, Logan Gunthorpe wrote: > > > >> +enum pci_p2pdma_map_type > >> +pci_p2pdma_map_segment(struct pci_p2pdma_map_state *state,

RE: [RFC 08/20] vfio/pci: Add VFIO_DEVICE_BIND_IOMMUFD

2021-09-29 Thread Tian, Kevin
> From: Jason Gunthorpe > Sent: Wednesday, September 29, 2021 8:28 PM > > On Wed, Sep 29, 2021 at 06:41:00AM +, Tian, Kevin wrote: > > > From: David Gibson > > > Sent: Wednesday, September 29, 2021 2:01 PM > > > > > > On Sun, Sep 19, 2021 at 02:38:36PM +0800, Liu Yi L wrote: > > > > This

Re: [PATCH v3 00/20] Userspace P2PDMA with O_DIRECT NVMe devices

2021-09-29 Thread Logan Gunthorpe
On 2021-09-28 2:02 p.m., Jason Gunthorpe wrote: > On Thu, Sep 16, 2021 at 05:40:40PM -0600, Logan Gunthorpe wrote: >> Hi, >> >> This patchset continues my work to add userspace P2PDMA access using >> O_DIRECT NVMe devices. My last posting[1] just included the first 13 >> patches in this series,

Re: [PATCH v3 19/20] PCI/P2PDMA: introduce pci_mmap_p2pmem()

2021-09-29 Thread Logan Gunthorpe
On 2021-09-28 2:05 p.m., Jason Gunthorpe wrote: > On Thu, Sep 16, 2021 at 05:40:59PM -0600, Logan Gunthorpe wrote: > >> +static void pci_p2pdma_unmap_mappings(void *data) >> +{ >> +struct pci_dev *pdev = data; >> +struct pci_p2pdma *p2pdma = rcu_dereference_protected(pdev->p2pdma, 1);

Re: [PATCH v3 19/20] PCI/P2PDMA: introduce pci_mmap_p2pmem()

2021-09-29 Thread Logan Gunthorpe
On 2021-09-28 1:55 p.m., Jason Gunthorpe wrote: > On Thu, Sep 16, 2021 at 05:40:59PM -0600, Logan Gunthorpe wrote: >> +int pci_mmap_p2pmem(struct pci_dev *pdev, struct vm_area_struct *vma) >> +{ >> +struct pci_p2pdma_map *pmap; >> +struct pci_p2pdma *p2pdma; >> +int ret; >> + >> +

Re: [PATCH v3 14/20] mm: introduce FOLL_PCI_P2PDMA to gate getting PCI P2PDMA pages

2021-09-29 Thread Logan Gunthorpe
On 2021-09-28 1:47 p.m., Jason Gunthorpe wrote: > On Thu, Sep 16, 2021 at 05:40:54PM -0600, Logan Gunthorpe wrote: >> Callers that expect PCI P2PDMA pages can now set FOLL_PCI_P2PDMA to >> allow obtaining P2PDMA pages. If a caller does not set this flag >> and tries to map P2PDMA pages it will

Re: [PATCH v3 4/20] PCI/P2PDMA: introduce helpers for dma_map_sg implementations

2021-09-29 Thread Logan Gunthorpe
On 2021-09-28 4:05 p.m., Jason Gunthorpe wrote: > On Thu, Sep 16, 2021 at 05:40:44PM -0600, Logan Gunthorpe wrote: > >> +enum pci_p2pdma_map_type >> +pci_p2pdma_map_segment(struct pci_p2pdma_map_state *state, struct device >> *dev, >> + struct scatterlist *sg) >> +{ >> +

Re: [PATCH v3 04/20] PCI/P2PDMA: introduce helpers for dma_map_sg implementations

2021-09-29 Thread Logan Gunthorpe
On 2021-09-28 12:55 p.m., Jason Gunthorpe wrote: > On Thu, Sep 16, 2021 at 05:40:44PM -0600, Logan Gunthorpe wrote: >> Add pci_p2pdma_map_segment() as a helper for simple dma_map_sg() >> implementations. It takes an scatterlist segment that must point to a >> pci_p2pdma struct page and will map

Re: [PATCH v3 01/20] lib/scatterlist: add flag for indicating P2PDMA segments in an SGL

2021-09-29 Thread Logan Gunthorpe
On 2021-09-28 12:32 p.m., Jason Gunthorpe wrote: > On Thu, Sep 16, 2021 at 05:40:41PM -0600, Logan Gunthorpe wrote: >> config PCI_P2PDMA >> bool "PCI peer-to-peer transfer support" >> -depends on ZONE_DEVICE >> +depends on ZONE_DEVICE && 64BIT > > Perhaps a comment to explain what

Re: [PATCH 5/8] x86/mmu: Add mm-based PASID refcounting

2021-09-29 Thread Thomas Gleixner
On Wed, Sep 29 2021 at 11:31, Tony Luck wrote: > diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c > index a58800973aed..5a3c87fd65de 100644 > --- a/arch/x86/kernel/traps.c > +++ b/arch/x86/kernel/traps.c > @@ -528,6 +528,32 @@ static enum kernel_gp_hint get_kernel_gp_address(struct

Re: [RFC 0/7] Support in-kernel DMA with PASID and SVA

2021-09-29 Thread Jason Gunthorpe via iommu
On Wed, Sep 29, 2021 at 12:37:19PM -0700, Jacob Pan wrote: > For #2, it seems we can store the kernel PASID in struct device. This will > preserve the DMA API interface while making it PASID capable. Essentially, > each PASID capable device would have two special global PASIDs: > - PASID

Re: [RFC 0/7] Support in-kernel DMA with PASID and SVA

2021-09-29 Thread Jacob Pan
Hi, Just to follow up on what we discussed during LPC VFIO/IOMMU/PCI MC. https://linuxplumbersconf.org/event/11/contributions/1021/ The key takeaways are: 1. Addressing mode selections (PA, IOVA, and KVA) should be a policy decision *not* to be made by device drivers. This implies that it is up

Re: [RFC 02/20] vfio: Add device class for /dev/vfio/devices

2021-09-29 Thread Alex Williamson
On Wed, 29 Sep 2021 12:08:59 +1000 David Gibson wrote: > On Sun, Sep 19, 2021 at 02:38:30PM +0800, Liu Yi L wrote: > > This patch introduces a new interface (/dev/vfio/devices/$DEVICE) for > > userspace to directly open a vfio device w/o relying on container/group > > (/dev/vfio/$GROUP).

Re: [PATCH 5/8] x86/mmu: Add mm-based PASID refcounting

2021-09-29 Thread Luck, Tony
On Wed, Sep 29, 2021 at 06:07:22PM +, Fenghua Yu wrote: > Add > +#ifdef CONFIG_IOMMU_SUPPORT > because mm->pasid and current-pasid_activated are defined only if > CONFIG_IOMMU_SUPPORT is defined. > > > + if (user_mode(regs) && current->mm->pasid && !current->pasid_activated) > > { > >

Re: [PATCH] [RFC] qcom_scm: hide Kconfig symbol

2021-09-29 Thread Arnd Bergmann
On Wed, Sep 29, 2021 at 4:46 PM Bjorn Andersson wrote: > > On Wed 29 Sep 05:04 CDT 2021, Arnd Bergmann wrote: > > > On Wed, Sep 29, 2021 at 11:51 AM Will Deacon wrote: > > > On Mon, Sep 27, 2021 at 05:22:13PM +0200, Arnd Bergmann wrote: > > > > > > > > diff --git a/drivers/iommu/Kconfig

Re: [PATCH 5/8] x86/mmu: Add mm-based PASID refcounting

2021-09-29 Thread Fenghua Yu
Hi, Tony, On Wed, Sep 29, 2021 at 10:41:42AM -0700, Luck, Tony wrote: > On Wed, Sep 29, 2021 at 07:15:53PM +0200, Thomas Gleixner wrote: > > On Wed, Sep 29 2021 at 09:59, Andy Lutomirski wrote: > > > On 9/29/21 05:28, Thomas Gleixner wrote: > > >> Looking at that patch again, none of this muck in

Re: [PATCH 4/8] x86/traps: Demand-populate PASID MSR via #GP

2021-09-29 Thread Andy Lutomirski
On Wed, Sep 29, 2021, at 10:07 AM, Luck, Tony wrote: > On Wed, Sep 29, 2021 at 09:58:22AM -0700, Andy Lutomirski wrote: >> On 9/28/21 16:10, Luck, Tony wrote: >> > Moving beyond pseudo-code and into compiles-but-probably-broken-code. >> > >> > >> > The intent of the functions below is that

Re: [PATCH 5/8] x86/mmu: Add mm-based PASID refcounting

2021-09-29 Thread Andy Lutomirski
On Wed, Sep 29, 2021, at 10:41 AM, Luck, Tony wrote: > On Wed, Sep 29, 2021 at 07:15:53PM +0200, Thomas Gleixner wrote: >> On Wed, Sep 29 2021 at 09:59, Andy Lutomirski wrote: >> > On 9/29/21 05:28, Thomas Gleixner wrote: >> >> Looking at that patch again, none of this muck in

Re: [PATCH 5/8] x86/mmu: Add mm-based PASID refcounting

2021-09-29 Thread Luck, Tony
On Wed, Sep 29, 2021 at 07:15:53PM +0200, Thomas Gleixner wrote: > On Wed, Sep 29 2021 at 09:59, Andy Lutomirski wrote: > > On 9/29/21 05:28, Thomas Gleixner wrote: > >> Looking at that patch again, none of this muck in fpu__pasid_write() is > >> required at all. The whole exception fixup is: > >>

Re: [PATCH 5/8] x86/mmu: Add mm-based PASID refcounting

2021-09-29 Thread Thomas Gleixner
On Wed, Sep 29 2021 at 09:59, Andy Lutomirski wrote: > On 9/29/21 05:28, Thomas Gleixner wrote: >> Looking at that patch again, none of this muck in fpu__pasid_write() is >> required at all. The whole exception fixup is: >> >> if (!user_mode(regs)) >> return false; >> >>

Re: [PATCH 5/8] x86/mmu: Add mm-based PASID refcounting

2021-09-29 Thread Fenghua Yu
Hi, Thomas, On Wed, Sep 29, 2021 at 09:51:15AM -0700, Luck, Tony wrote: > > There is zero requirement to look at TIF_NEED_FPU_LOAD or > > fpregs_state_valid() simply because the #GP comes straight from user > > space which means the FPU registers contain the current tasks user space > > state. >

Re: [PATCH 4/8] x86/traps: Demand-populate PASID MSR via #GP

2021-09-29 Thread Luck, Tony
On Wed, Sep 29, 2021 at 09:58:22AM -0700, Andy Lutomirski wrote: > On 9/28/21 16:10, Luck, Tony wrote: > > Moving beyond pseudo-code and into compiles-but-probably-broken-code. > > > > > > The intent of the functions below is that Fenghua should be able to > > do: > > > > void

Re: [PATCH 5/8] x86/mmu: Add mm-based PASID refcounting

2021-09-29 Thread Andy Lutomirski
On 9/29/21 05:28, Thomas Gleixner wrote: On Wed, Sep 29 2021 at 11:54, Peter Zijlstra wrote: On Fri, Sep 24, 2021 at 04:03:53PM -0700, Andy Lutomirski wrote: I think the perfect and the good are a bit confused here. If we go for "good", then we have an mm owning a PASID for its entire

Re: [PATCH 4/8] x86/traps: Demand-populate PASID MSR via #GP

2021-09-29 Thread Andy Lutomirski
On 9/28/21 16:10, Luck, Tony wrote: Moving beyond pseudo-code and into compiles-but-probably-broken-code. The intent of the functions below is that Fenghua should be able to do: void fpu__pasid_write(u32 pasid) { u64 msr_val = pasid | MSR_IA32_PASID_VALID; struct

RE: [PATCH 5/8] x86/mmu: Add mm-based PASID refcounting

2021-09-29 Thread Luck, Tony
> There is zero requirement to look at TIF_NEED_FPU_LOAD or > fpregs_state_valid() simply because the #GP comes straight from user > space which means the FPU registers contain the current tasks user space > state. Just to double confirm ... there is no point in the #GP handler up to this point

Re: [PATCH v8 03/12] iommu/mediatek: Add probe_defer for smi-larb

2021-09-29 Thread Dafna Hirschfeld
On 29.09.21 03:37, Yong Wu wrote: Prepare for adding device_link. The iommu consumer should use device_link to connect with the smi-larb(supplier). then the smi-larb should run before the iommu consumer. Here we delay the iommu driver until the smi driver is ready, then all the iommu

Re: [PATCH 2/2] [v2] qcom_scm: hide Kconfig symbol

2021-09-29 Thread Bjorn Andersson
On Tue 28 Sep 02:50 CDT 2021, Arnd Bergmann wrote: > From: Arnd Bergmann > > Now that SCM can be a loadable module, we have to add another > dependency to avoid link failures when ipa or adreno-gpu are > built-in: > > aarch64-linux-ld: drivers/net/ipa/ipa_main.o: in function `ipa_probe': >

Re: [PATCH] [RFC] qcom_scm: hide Kconfig symbol

2021-09-29 Thread Bjorn Andersson
On Wed 29 Sep 05:04 CDT 2021, Arnd Bergmann wrote: > On Wed, Sep 29, 2021 at 11:51 AM Will Deacon wrote: > > On Mon, Sep 27, 2021 at 05:22:13PM +0200, Arnd Bergmann wrote: > > > > > > diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig > > > index 124c41adeca1..989c83acbfee 100644 > > >

Re: [RFC 06/20] iommu: Add iommu_device_init[exit]_user_dma interfaces

2021-09-29 Thread Jason Gunthorpe via iommu
On Wed, Sep 29, 2021 at 12:38:35AM +, Tian, Kevin wrote: > /* If set the driver must call iommu_XX as the first action in probe() or > * before it attempts to do DMA > */ > bool suppress_dma_owner:1; It is not "attempts to do DMA" but more "operates the physical device in any away" Not

Re: [RFC 06/20] iommu: Add iommu_device_init[exit]_user_dma interfaces

2021-09-29 Thread Jason Gunthorpe via iommu
On Wed, Sep 29, 2021 at 04:35:19PM +1000, David Gibson wrote: > Yes, exactly. And with a group interface it's obvious it has to > understand it. With the non-group interface, you can get to this > stage in ignorance of groups. It will even work as long as you are > lucky enough only to try

Re: [RFC 10/20] iommu/iommufd: Add IOMMU_DEVICE_GET_INFO

2021-09-29 Thread Jason Gunthorpe via iommu
On Wed, Sep 29, 2021 at 08:48:28AM +, Tian, Kevin wrote: > ARM: > - set to snoop format if IOMMU_CACHE > - set to nonsnoop format if !IOMMU_CACHE > (in both cases TLP snoop bit is ignored?) Where do you see this? I couldn't even find this functionality in the ARM HW manual?? What I

Re: [RFC 17/20] iommu/iommufd: Report iova range to userspace

2021-09-29 Thread Jason Gunthorpe via iommu
On Wed, Sep 29, 2021 at 01:07:56PM +0100, Jean-Philippe Brucker wrote: > Yes, so the guest knows the size of GPA it can write into the page table. > For Arm SMMU the GPA size is determined by both the SMMU implementation > and the host kernel configuration. But maybe that could also be >

Re: [PATCH 5/8] x86/mmu: Add mm-based PASID refcounting

2021-09-29 Thread Thomas Gleixner
On Wed, Sep 29 2021 at 11:54, Peter Zijlstra wrote: > On Fri, Sep 24, 2021 at 04:03:53PM -0700, Andy Lutomirski wrote: >> I think the perfect and the good are a bit confused here. If we go for >> "good", then we have an mm owning a PASID for its entire lifetime. If >> we want "perfect", then we

Re: [RFC 08/20] vfio/pci: Add VFIO_DEVICE_BIND_IOMMUFD

2021-09-29 Thread Jason Gunthorpe via iommu
On Wed, Sep 29, 2021 at 06:41:00AM +, Tian, Kevin wrote: > > From: David Gibson > > Sent: Wednesday, September 29, 2021 2:01 PM > > > > On Sun, Sep 19, 2021 at 02:38:36PM +0800, Liu Yi L wrote: > > > This patch adds VFIO_DEVICE_BIND_IOMMUFD for userspace to bind the > > vfio > > > device to

Re: [RFC 07/20] iommu/iommufd: Add iommufd_[un]bind_device()

2021-09-29 Thread Jason Gunthorpe via iommu
On Wed, Sep 29, 2021 at 03:25:54PM +1000, David Gibson wrote: > > +struct iommufd_device { > > + unsigned int id; > > + struct iommufd_ctx *ictx; > > + struct device *dev; /* always be the physical device */ > > + u64 dev_cookie; > > Why do you need both an 'id' and a 'dev_cookie'?

Re: [RFC 03/20] vfio: Add vfio_[un]register_device()

2021-09-29 Thread Jason Gunthorpe via iommu
On Wed, Sep 29, 2021 at 12:46:14PM +1000, da...@gibson.dropbear.id.au wrote: > On Tue, Sep 21, 2021 at 10:00:14PM -0300, Jason Gunthorpe wrote: > > On Wed, Sep 22, 2021 at 12:54:02AM +, Tian, Kevin wrote: > > > > From: Jason Gunthorpe > > > > Sent: Wednesday, September 22, 2021 12:01 AM > > >

Re: [RFC 03/20] vfio: Add vfio_[un]register_device()

2021-09-29 Thread Jason Gunthorpe via iommu
On Wed, Sep 29, 2021 at 09:08:25AM +0200, Cornelia Huck wrote: > On Wed, Sep 29 2021, "Tian, Kevin" wrote: > > >> From: David Gibson > >> Sent: Wednesday, September 29, 2021 10:44 AM > >> > >> > One alternative option is to arrange device nodes in sub-directories > >> > based > >> > on the

Re: [PATCH v8 09/12] media: mtk-vcodec: Get rid of mtk_smi_larb_get/put

2021-09-29 Thread Dafna Hirschfeld
On 29.09.21 03:37, Yong Wu wrote: MediaTek IOMMU has already added the device_link between the consumer and smi-larb device. If the vcodec device call the pm_runtime_get_sync, the smi-larb's pm_runtime_get_sync also be called automatically. CC: Tiffany Lin CC: Irui Wang Signed-off-by: Yong

Re: [RFC 17/20] iommu/iommufd: Report iova range to userspace

2021-09-29 Thread Jean-Philippe Brucker
On Wed, Sep 29, 2021 at 10:44:01AM +, Liu, Yi L wrote: > > From: Jean-Philippe Brucker > > Sent: Wednesday, September 22, 2021 10:49 PM > > > > On Sun, Sep 19, 2021 at 02:38:45PM +0800, Liu Yi L wrote: > > > [HACK. will fix in v2] > > > > > > IOVA range is critical info for userspace to

RE: [RFC 11/20] iommu/iommufd: Add IOMMU_IOASID_ALLOC/FREE

2021-09-29 Thread Liu, Yi L
> From: Jean-Philippe Brucker > Sent: Wednesday, September 22, 2021 9:45 PM > > On Sun, Sep 19, 2021 at 02:38:39PM +0800, Liu Yi L wrote: > > This patch adds IOASID allocation/free interface per iommufd. When > > allocating an IOASID, userspace is expected to specify the type and > > format

RE: [RFC 17/20] iommu/iommufd: Report iova range to userspace

2021-09-29 Thread Liu, Yi L
> From: Jean-Philippe Brucker > Sent: Wednesday, September 22, 2021 10:49 PM > > On Sun, Sep 19, 2021 at 02:38:45PM +0800, Liu Yi L wrote: > > [HACK. will fix in v2] > > > > IOVA range is critical info for userspace to manage DMA for an I/O address > > space. This patch reports the valid iova

Re: [PATCH] [RFC] qcom_scm: hide Kconfig symbol

2021-09-29 Thread Arnd Bergmann
On Wed, Sep 29, 2021 at 11:51 AM Will Deacon wrote: > On Mon, Sep 27, 2021 at 05:22:13PM +0200, Arnd Bergmann wrote: > > > > diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig > > index 124c41adeca1..989c83acbfee 100644 > > --- a/drivers/iommu/Kconfig > > +++ b/drivers/iommu/Kconfig > >

Re: [PATCH 5/8] x86/mmu: Add mm-based PASID refcounting

2021-09-29 Thread Peter Zijlstra
On Fri, Sep 24, 2021 at 04:03:53PM -0700, Andy Lutomirski wrote: > I think the perfect and the good are a bit confused here. If we go for > "good", then we have an mm owning a PASID for its entire lifetime. If > we want "perfect", then we should actually do it right: teach the > kernel to update

Re: [PATCH] [RFC] qcom_scm: hide Kconfig symbol

2021-09-29 Thread Will Deacon
On Mon, Sep 27, 2021 at 05:22:13PM +0200, Arnd Bergmann wrote: > From: Arnd Bergmann > > Now that SCM can be a loadable module, we have to add another > dependency to avoid link failures when ipa or adreno-gpu are > built-in: > > aarch64-linux-ld: drivers/net/ipa/ipa_main.o: in function

Re: [RFC 04/20] iommu: Add iommu_device_get_info interface

2021-09-29 Thread Lu Baolu
On 2021/9/29 17:25, Lu Baolu wrote: Hi David, On 2021/9/29 10:52, David Gibson wrote: On Sun, Sep 19, 2021 at 02:38:32PM +0800, Liu Yi L wrote: From: Lu Baolu This provides an interface for upper layers to get the per-device iommu attributes. int iommu_device_get_info(struct device

Re: [RFC 04/20] iommu: Add iommu_device_get_info interface

2021-09-29 Thread Lu Baolu
Hi David, On 2021/9/29 10:52, David Gibson wrote: On Sun, Sep 19, 2021 at 02:38:32PM +0800, Liu Yi L wrote: From: Lu Baolu This provides an interface for upper layers to get the per-device iommu attributes. int iommu_device_get_info(struct device *dev,

Re: [PATCH 4/8] x86/traps: Demand-populate PASID MSR via #GP

2021-09-29 Thread Peter Zijlstra
On Fri, Sep 24, 2021 at 08:39:24AM -0700, Luck, Tony wrote: > If you have ctags installed then a ctrl-] on that > __fixup_pasid_exception() will take you to the function with > the comments. No electron microscope needed. I to use ctags, but when reading the #GP handler, this is a whole

RE: [RFC 10/20] iommu/iommufd: Add IOMMU_DEVICE_GET_INFO

2021-09-29 Thread Tian, Kevin
+Robin. > From: Jason Gunthorpe > Sent: Thursday, September 23, 2021 8:22 PM > > On Thu, Sep 23, 2021 at 12:05:29PM +, Tian, Kevin wrote: > > > From: Jason Gunthorpe > > > Sent: Thursday, September 23, 2021 7:27 PM > > > > > > On Thu, Sep 23, 2021 at 11:15:24AM +0100, Jean-Philippe Brucker

Re: [PATCH 1/8] iommu/vt-d: Clean up unused PASID updating functions

2021-09-29 Thread Lu Baolu
Hi Fenghua, On 2021/9/21 3:23, Fenghua Yu wrote: update_pasid() and its call chain are currently unused in the tree because Thomas disabled the ENQCMD feature. The feature will be re-enabled shortly using a different approach and update_pasid() and its call chain will not be used in the new

RE: [RFC 06/20] iommu: Add iommu_device_init[exit]_user_dma interfaces

2021-09-29 Thread Tian, Kevin
> From: David Gibson > Sent: Wednesday, September 29, 2021 2:35 PM > > On Wed, Sep 29, 2021 at 05:38:56AM +, Tian, Kevin wrote: > > > From: David Gibson > > > Sent: Wednesday, September 29, 2021 12:56 PM > > > > > > > > > > > Unlike vfio, iommufd adopts a device-centric design with all group

[PATCH 1/1] iommu/vt-d: Delete dev_has_feat callback

2021-09-29 Thread Lu Baolu
The commit 262948f8ba573 ("iommu: Delete iommu_dev_has_feature()") has deleted the iommu_dev_has_feature() interface. Remove the dev_has_feat callback to avoid dead code. Signed-off-by: Lu Baolu --- drivers/iommu/intel/iommu.c | 59 - 1 file changed, 5

Re: [RFC 06/20] iommu: Add iommu_device_init[exit]_user_dma interfaces

2021-09-29 Thread David Gibson
On Wed, Sep 29, 2021 at 05:38:56AM +, Tian, Kevin wrote: > > From: David Gibson > > Sent: Wednesday, September 29, 2021 12:56 PM > > > > > > > > Unlike vfio, iommufd adopts a device-centric design with all group > > > logistics hidden behind the fd. Binding a device to iommufd serves > > >

RE: [RFC 03/20] vfio: Add vfio_[un]register_device()

2021-09-29 Thread Cornelia Huck
On Wed, Sep 29 2021, "Tian, Kevin" wrote: >> From: David Gibson >> Sent: Wednesday, September 29, 2021 10:44 AM >> >> > One alternative option is to arrange device nodes in sub-directories based >> > on the device type. But doing so also adds one trouble to userspace. The >> > current vfio

RE: [RFC 08/20] vfio/pci: Add VFIO_DEVICE_BIND_IOMMUFD

2021-09-29 Thread Tian, Kevin
> From: David Gibson > Sent: Wednesday, September 29, 2021 2:01 PM > > On Sun, Sep 19, 2021 at 02:38:36PM +0800, Liu Yi L wrote: > > This patch adds VFIO_DEVICE_BIND_IOMMUFD for userspace to bind the > vfio > > device to an iommufd. No VFIO_DEVICE_UNBIND_IOMMUFD interface is > provided > >

Re: [RFC 07/20] iommu/iommufd: Add iommufd_[un]bind_device()

2021-09-29 Thread David Gibson
On Sun, Sep 19, 2021 at 02:38:35PM +0800, Liu Yi L wrote: > Under the /dev/iommu model, iommufd provides the interface for I/O page > tables management such as dma map/unmap. However, it cannot work > independently since the device is still owned by the device-passthrough > frameworks (VFIO, vDPA,

Re: [RFC 10/20] iommu/iommufd: Add IOMMU_DEVICE_GET_INFO

2021-09-29 Thread da...@gibson.dropbear.id.au
On Wed, Sep 22, 2021 at 09:41:50AM -0300, Jason Gunthorpe wrote: > On Wed, Sep 22, 2021 at 03:30:09AM +, Tian, Kevin wrote: > > > From: Jason Gunthorpe > > > Sent: Wednesday, September 22, 2021 1:41 AM > > > > > > On Sun, Sep 19, 2021 at 02:38:38PM +0800, Liu Yi L wrote: > > > > After a

Re: [RFC 08/20] vfio/pci: Add VFIO_DEVICE_BIND_IOMMUFD

2021-09-29 Thread David Gibson
On Sun, Sep 19, 2021 at 02:38:36PM +0800, Liu Yi L wrote: > This patch adds VFIO_DEVICE_BIND_IOMMUFD for userspace to bind the vfio > device to an iommufd. No VFIO_DEVICE_UNBIND_IOMMUFD interface is provided > because it's implicitly done when the device fd is closed. > > In concept a vfio device

Re: [RFC 10/20] iommu/iommufd: Add IOMMU_DEVICE_GET_INFO

2021-09-29 Thread David Gibson
On Sun, Sep 19, 2021 at 02:38:38PM +0800, Liu Yi L wrote: > After a device is bound to the iommufd, userspace can use this interface > to query the underlying iommu capability and format info for this device. > Based on this information the user then creates I/O address space in a > compatible