Re: [PATCH 2/3] iommu/io-pgtable-arm: Add IOMMU_LLC page protection flag

2021-03-08 Thread Sai Prakash Ranjan
Hi, On 2021-02-05 17:38, Sai Prakash Ranjan wrote: On 2021-02-04 03:16, Will Deacon wrote: On Tue, Feb 02, 2021 at 11:56:27AM +0530, Sai Prakash Ranjan wrote: On 2021-02-01 23:50, Jordan Crouse wrote: > On Mon, Feb 01, 2021 at 08:20:44AM -0800, Rob Clark wrote: > > On Mon, Feb 1, 2021 at 3:16

[RFC PATCH v2 6/6] vfio: Add nested IOPF support

2021-03-08 Thread Shenming Lu
To set up nested mode, drivers such as vfio_pci have to register a handler to receive stage/level 1 faults from the IOMMU, but since currently each device can only have one iommu dev fault handler, and if stage 2 IOPF is already enabled (VFIO_IOMMU_ENABLE_IOPF), we choose to update the registered

[RFC PATCH v2 4/6] vfio: VFIO_IOMMU_ENABLE_IOPF

2021-03-08 Thread Shenming Lu
Since enabling IOPF for devices may lead to a slow ramp up of performance, we add an VFIO_IOMMU_ENABLE_IOPF ioctl to make it configurable. And the IOPF enabling of a VFIO device includes setting IOMMU_DEV_FEAT_IOPF and registering the VFIO page fault handler. Note that VFIO_IOMMU_DISABLE_IOPF is

[RFC PATCH v2 5/6] vfio: No need to statically pin and map if IOPF enabled

2021-03-08 Thread Shenming Lu
If IOPF enabled for the VFIO container, there is no need to statically pin and map the entire DMA range, we can do it on demand. And unmap according to the IOPF mapped bitmap when removing vfio_dma. Signed-off-by: Shenming Lu --- drivers/vfio/vfio_iommu_type1.c | 35

[RFC PATCH v2 3/6] vfio: Add a page fault handler

2021-03-08 Thread Shenming Lu
VFIO manages the DMA mapping itself. To support IOPF for VFIO devices, we add a VFIO page fault handler to serve the reported page faults from the IOMMU driver. Besides, we can pre-map more pages than requested at once to optimize for fewer page fault handlings. Signed-off-by: Shenming Lu ---

[RFC PATCH v2 1/6] iommu: Evolve to support more scenarios of using IOPF

2021-03-08 Thread Shenming Lu
This patch follows the discussion here: https://lore.kernel.org/linux-acpi/YAaxjmJW+ZMvrhac@myrica/ In order to support more scenarios of using IOPF (mainly consider the nested extension), besides keeping IOMMU_DEV_FEAT_IOPF as a general capability for whether delivering faults through the

[RFC PATCH v2 2/6] vfio: Add an MMU notifier to avoid pinning

2021-03-08 Thread Shenming Lu
To avoid pinning pages when they are mapped in IOMMU page tables, we add an MMU notifier to tell the addresses which are no longer valid and try to unmap them. Signed-off-by: Shenming Lu --- drivers/vfio/vfio_iommu_type1.c | 68 + 1 file changed, 68 insertions(+)

[RFC PATCH v2 0/6] Add IOPF support for VFIO passthrough

2021-03-08 Thread Shenming Lu
Hi, The static pinning and mapping problem in VFIO and possible solutions have been discussed a lot [1, 2]. One of the solutions is to add I/O page fault support for VFIO devices. Different from those relatively complicated software approaches such as presenting a vIOMMU that provides the DMA

[PATCH 1/1] iommu/vt-d: Don't set then immediately clear in prq_event_thread()

2021-03-08 Thread Lu Baolu
The private data field of a page group response descriptor is set then immediately cleared in prq_event_thread(). Fix this by moving clearing code up. Fixes: 5b438f4ba315d ("iommu/vt-d: Support page request in scalable mode") Cc: Jacob Pan Reviewed-by: Liu Yi L Signed-off-by: Lu Baolu ---

Re: [PATCH 2/5] iommu/vt-d: Remove WO permissions on second-level paging entries

2021-03-08 Thread Raj, Ashok
Hi Joerg On Mon, Mar 08, 2021 at 09:58:26AM +0800, Lu Baolu wrote: > Hi Joerg, > > On 3/4/21 8:26 PM, Joerg Roedel wrote: > >On Thu, Feb 25, 2021 at 02:26:51PM +0800, Lu Baolu wrote: > >>When the first level page table is used for IOVA translation, it only > >>supports Read-Only and Read-Write

Re: [PATCH v12 03/13] vfio: VFIO_IOMMU_SET_MSI_BINDING

2021-03-08 Thread Auger Eric
Hi Jean, On 3/5/21 11:45 AM, Jean-Philippe Brucker wrote: > Hi, > > On Tue, Feb 23, 2021 at 10:06:15PM +0100, Eric Auger wrote: >> This patch adds the VFIO_IOMMU_SET_MSI_BINDING ioctl which aim >> to (un)register the guest MSI binding to the host. This latter >> then can use those stage 1

Re: [PATCH 1/1] Revert "iommu/iova: Retry from last rb tree node if iova search fails"

2021-03-08 Thread John Garry
On 08/03/2021 15:15, Robin Murphy wrote: I figure that you're talking about 4e89dce72521 now. I would have liked to know which real-life problem it solved in practice. From what I remember, the problem reported was basically the one illustrated in that commit and the one I alluded to above -

Re: [PATCH 1/1] Revert "iommu/iova: Retry from last rb tree node if iova search fails"

2021-03-08 Thread Robin Murphy
On 2021-03-01 15:48, John Garry wrote: On 01/03/2021 13:20, Robin Murphy wrote: FWIW, I'm 99% sure that what you really want is [1], but then you get to battle against an unknown quantity of dodgy firmware instead. Something which has not been said before is that this only happens for strict

Re: [PATCH] iommu/dma: Resurrect the "forcedac" option

2021-03-08 Thread John Garry
On 08/03/2021 13:08, Robin Murphy wrote: On 2021-03-05 17:41, John Garry wrote: On 05/03/2021 16:32, Robin Murphy wrote: In converting intel-iommu over to the common IOMMU DMA ops, it quietly lost the functionality of its "forcedac" option. Since this is a handy thing both for testing and for

Re: [PATCH] iommu/dma: Resurrect the "forcedac" option

2021-03-08 Thread Robin Murphy
On 2021-03-05 17:41, John Garry wrote: On 05/03/2021 16:32, Robin Murphy wrote: In converting intel-iommu over to the common IOMMU DMA ops, it quietly lost the functionality of its "forcedac" option. Since this is a handy thing both for testing and for performance optimisation on certain