Hi Jacob,
On 4/3/20 8:42 PM, Jacob Pan wrote:
> When VT-d driver runs in the guest, PASID allocation must be
> performed via virtual command interface. This patch registers a
> custom IOASID allocator which takes precedence over the default
> XArray based allocator. The resulting IOASID
Hi Jacob,
On 4/3/20 8:42 PM, Jacob Pan wrote:
> Virtual command registers are used in the guest only, to prevent
> vmexit cost, we cache the capability and store it during initialization.
>
> Signed-off-by: Jacob Pan
> Reviewed-by: Eric Auger
> Reviewed-by: Lu Baolu
nit: following Joerg's
Hi Jean,
On 4/9/20 10:14 AM, Jean-Philippe Brucker wrote:
> On Wed, Apr 08, 2020 at 12:27:58PM +0200, Auger Eric wrote:
>> Hi Yi,
>>
>> On 4/7/20 11:43 AM, Liu, Yi L wrote:
>>> Hi Jean,
>>>
>>>> From: Jean-Philippe Brucker
>>&
Hi Jacob,
On 4/3/20 8:42 PM, Jacob Pan wrote:
> When Shared Virtual Address (SVA) is enabled for a guest OS via
> vIOMMU, we need to provide invalidation support at IOMMU API and driver
> level. This patch adds Intel VT-d specific function to implement
> iommu passdown invalidate API for shared
Hi Jacob,
On 4/3/20 8:42 PM, Jacob Pan wrote:
> When supporting guest SVA with emulated IOMMU, the guest PASID
> table is shadowed in VMM. Updates to guest vIOMMU PASID table
> will result in PASID cache flush which will be passed down to
> the host as bind guest PASID calls.
>
> For the SL page
Hi Jacob,
On 4/3/20 8:42 PM, Jacob Pan wrote:
> Nested translation mode is supported in VT-d 3.0 Spec.CH 3.8.
> With PASID granular translation type set to 0x11b, translation
> result from the first level(FL) also subject to a second level(SL)
> page table translation. This mode is used for SVA
Hi Yi,
On 4/7/20 11:43 AM, Liu, Yi L wrote:
> Hi Jean,
>
>> From: Jean-Philippe Brucker
>> Sent: Friday, April 3, 2020 4:23 PM
>> To: Auger Eric
>> userspace
>>
>> On Wed, Apr 01, 2020 at 03:01:12PM +0200, Auger Eric wrote:
>>>>>>
Hi Jacob,
On 4/3/20 8:42 PM, Jacob Pan wrote:
> When Shared Virtual Memory is exposed to a guest via vIOMMU, scalable
> IOTLB invalidation may be passed down from outside IOMMU subsystems.
> This patch adds invalidation functions that can be used for additional
> translation cache types.
>
>
other places.
>
> ---
> v11 Added Baolu's commit message and squashed 4 & 5 from v10.
> ---
>
> Signed-off-by: Jacob Pan
> Signed-off-by: Lu Baolu
Reviewed-by: Eric Auger
Eric
> ---
> drivers/iommu/intel-pasid.c | 34 --
>
Hi Yi,
On 4/1/20 3:18 PM, Liu, Yi L wrote:
> Hi Eric,
>
> Just curious about your plan on this patch, I just heard my colleague would
> like
> to reference the functions from this patch in his dsa driver work.
Well I intend to respin until somebody tells me it is completely vain or
dead
Hi Yi,
On 4/1/20 2:51 PM, Liu, Yi L wrote:
> Hi Eric,
>
>> From: Auger Eric
>> Sent: Wednesday, April 1, 2020 4:51 PM
>> To: Liu, Yi L ; alex.william...@redhat.com
>> Subject: Re: [PATCH v1 5/8] vfio/type1: Report 1st-level/stage-1 format to
>> userspace
>
Yi,
On 3/22/20 1:32 PM, Liu, Yi L wrote:
> From: Liu Yi L
>
> This patch reports PASID alloc/free availability to userspace (e.g. QEMU)
> thus userspace could do a pre-check before utilizing this feature.
>
> Cc: Kevin Tian
> CC: Jacob Pan
> Cc: Alex Williamson
> Cc: Eric Auger
> Cc:
Hi Yi,
On 3/22/20 1:32 PM, Liu, Yi L wrote:
> From: Liu Yi L
>
> VFIO exposes IOMMU nesting translation (a.k.a dual stage translation)
> capability to userspace. Thus applications like QEMU could support
> vIOMMU with hardware's nesting translation capability for pass-through
> devices. Before
l 1, 2020 4:58 AM
>>>
>>> On Tue, 31 Mar 2020 02:49:21 +
>>> "Tian, Kevin" wrote:
>>>
>>>>> From: Auger Eric
>>>>> Sent: Sunday, March 29, 2020 11:34 PM
>>>>>
>>>>> Hi,
>>>>&g
Eric
>
> On Tue, 31 Mar 2020 11:28:17 +0200
> Auger Eric wrote:
>
>> Hi Jacob,
>>
>> On 3/31/20 1:25 AM, Jacob Pan wrote:
>>> PASID cache type and shift of granularity bits are missing in
>>> the current code.
>>>
>>> Fixes: 6f7db75e1c46
Hi Jacob,
On 3/31/20 6:13 PM, Jacob Pan wrote:
> On Mon, 30 Mar 2020 16:28:34 -0700
> Jacob Pan wrote:
>
>> On Fri, 27 Mar 2020 15:46:23 +0100
>> Auger Eric wrote:
>>
>>> Hi Jacob,
>>>
>>> On 3/21/20 12:27 AM, Jacob Pan wrote:
>>&g
Hi Andre,
On 3/12/20 7:19 PM, Andre Przywara wrote:
> When we try to get an MSI cookie for a VFIO device, that can fail if
> CONFIG_IOMMU_DMA is not set. In this case iommu_get_msi_cookie() returns
> -ENODEV, and that should not be fatal.
>
> Ignore that case and proceed with the initialisation.
Hi Jacob,
On 3/31/20 1:25 AM, Jacob Pan wrote:
> PASID cache type and shift of granularity bits are missing in
> the current code.
>
> Fixes: 6f7db75e1c46 ("iommu/vt-d: Add second level page table
> interface")
>
> Cc: Eric Auger
> Signed-off-by: Jacob Pan
Reviewed-by: Eric Auger
Thanks
Hi Jacob,
On 3/21/20 12:27 AM, Jacob Pan wrote:
> When Shared Virtual Address (SVA) is enabled for a guest OS via
> vIOMMU, we need to provide invalidation support at IOMMU API and driver
> level. This patch adds Intel VT-d specific function to implement
> iommu passdown invalidate API for shared
On 3/28/20 11:01 AM, Tian, Kevin wrote:
>> From: Jacob Pan
>> Sent: Saturday, March 21, 2020 7:28 AM
>>
>> When Shared Virtual Address (SVA) is enabled for a guest OS via
>> vIOMMU, we need to provide invalidation support at IOMMU API and driver
>> level. This patch adds Intel VT-d specific
Hi,
On 3/28/20 11:01 AM, Tian, Kevin wrote:
>> From: Jacob Pan
>> Sent: Saturday, March 21, 2020 7:28 AM
>>
>> When Shared Virtual Address (SVA) is enabled for a guest OS via
>> vIOMMU, we need to provide invalidation support at IOMMU API and driver
>> level. This patch adds Intel VT-d specific
Hi,
On 3/21/20 12:27 AM, Jacob Pan wrote:
> When supporting guest SVA with emulated IOMMU, the guest PASID
> table is shadowed in VMM. Updates to guest vIOMMU PASID table
> will result in PASID cache flush which will be passed down to
> the host as bind guest PASID calls.
>
> For the SL page
Hi Jacob,
On 3/21/20 12:27 AM, Jacob Pan wrote:
> Nested translation mode is supported in VT-d 3.0 Spec.CH 3.8.
> With PASID granular translation type set to 0x11b, translation
> result from the first level(FL) also subject to a second level(SL)
> page table translation. This mode is used for SVA
Hi Jacob,
On 3/27/20 12:55 PM, Tian, Kevin wrote:
>> From: Jacob Pan
>> Sent: Saturday, March 21, 2020 7:28 AM
>>
>> Signed-off-by: Jacob Pan
>> ---
>> drivers/iommu/intel-pasid.c | 14 --
>> 1 file changed, 4 insertions(+), 10 deletions(-)
>>
>> diff --git
Hi Jacob,
On 3/21/20 12:27 AM, Jacob Pan wrote:
> When Shared Virtual Memory is exposed to a guest via vIOMMU, scalable
> IOTLB invalidation may be passed down from outside IOMMU subsystems.
> This patch adds invalidation functions that can be used for additional
> translation cache types.
>
>
Hi Jacob,
On 3/21/20 12:27 AM, Jacob Pan wrote:
> Memory type related flags can be grouped together for one simple check.
>
> ---
> v9 renamed from EMT to MTS since these are memory type support flags.
> ---
>
> Signed-off-by: Jacob Pan
Reviewed-by: Eric Auger
Thanks
Eric
> ---
>
Hi Jean,
On 3/26/20 10:35 AM, Jean-Philippe Brucker wrote:
> We don't currently support IOMMUs with a page granule larger than the
> system page size. The IOVA allocator has a BUG_ON() in this case, and
> VFIO has a WARN_ON().
>
> Removing these obstacles ranges doesn't seem possible without
Hi Jean,
On 3/18/20 12:40 PM, Jean-Philippe Brucker wrote:
> We don't currently support IOMMUs with a page granule larger than the
> system page size. The IOVA allocator has a BUG_ON() in this case, and
> VFIO has a WARN_ON().
>
> It might be possible to remove these obstacles if necessary. If
Hi,
On 3/18/20 1:00 PM, Robin Murphy wrote:
> On 2020-03-18 11:40 am, Jean-Philippe Brucker wrote:
>> We don't currently support IOMMUs with a page granule larger than the
>> system page size. The IOVA allocator has a BUG_ON() in this case, and
>> VFIO has a WARN_ON().
Adding Alex in CC in case
Hi Andre,
On 3/13/20 3:08 PM, Robin Murphy wrote:
> On 2020-03-12 6:19 pm, Andre Przywara wrote:
>> When we try to get an MSI cookie for a VFIO device, that can fail if
>> CONFIG_IOMMU_DMA is not set. In this case iommu_get_msi_cookie() returns
>> -ENODEV, and that should not be fatal.
>>
>>
Hi Michael, Joerg,
On 3/3/20 5:09 PM, Michael S. Tsirkin wrote:
> On Tue, Mar 03, 2020 at 04:53:19PM +0100, Joerg Roedel wrote:
>> On Tue, Mar 03, 2020 at 09:00:05AM -0500, Michael S. Tsirkin wrote:
>>> Not necessarily. E.g. some power systems have neither.
>>> There are also systems looking to
Hi Zhangfei,
On 3/3/20 1:57 PM, zhangfei wrote:
> Hi, Eric
>
> On 2019/11/20 下午6:18, Auger Eric wrote:
>>
>>>> This series brings the VFIO part of HW nested paging support
>>>> in the SMMUv3.
>>>>
>>>> The series depends
Hi Joerg,
On 3/2/20 5:16 PM, Joerg Roedel wrote:
> On Fri, Feb 28, 2020 at 06:25:36PM +0100, Jean-Philippe Brucker wrote:
>> This solution isn't elegant nor foolproof, but is the best we can do at
>> the moment and works with existing virtio-iommu implementations. It also
>> enables an IOMMU for
Hi Jacob,
On 2/15/20 12:27 AM, Jacob Pan wrote:
> Hi Eric,
>
> On Wed, 12 Feb 2020 13:55:25 +0100
> Auger Eric wrote:
>
>> Hi Jacob,
>>
>> On 1/29/20 7:01 AM, Jacob Pan wrote:
>>> When Shared Virtual Memory is exposed to a guest via vIOMMU,
>>
Hi Rob, Alex,
On 2/18/20 6:13 PM, Rob Herring wrote:
> Cc: Eric Auger
> Cc: Alex Williamson
> Cc: Cornelia Huck
> Cc: k...@vger.kernel.org
> Signed-off-by: Rob Herring
> ---
> Do not apply yet.
>
> drivers/vfio/platform/reset/Kconfig | 8 --
> drivers/vfio/platform/reset/Makefile
Hi Rob,
On 2/13/20 8:54 PM, Rob Herring wrote:
> On Thu, Jan 30, 2020 at 9:06 AM Auger Eric wrote:
>>
>> Hi Rob,
>> On 1/17/20 10:16 PM, Rob Herring wrote:
>>> Arm SMMUv3.2 adds support for TLB range invalidate operations.
>>> Support for range invalidate i
Hi Jacob,
On 1/29/20 7:01 AM, Jacob Pan wrote:
> When Shared Virtual Address (SVA) is enabled for a guest OS via
> vIOMMU, we need to provide invalidation support at IOMMU API and driver
> level. This patch adds Intel VT-d specific function to implement
> iommu passdown invalidate API for shared
Hi Jacob,
On 1/29/20 7:01 AM, Jacob Pan wrote:
> Virtual command registers are used in the guest only, to prevent
> vmexit cost, we cache the capability and store it during initialization.
>
> Signed-off-by: Jacob Pan
I sent my R-b in https://lkml.org/lkml/2019/11/8/228
Also Baolo did. Do I
Hi Jacob,
On 1/29/20 7:01 AM, Jacob Pan wrote:
> When Shared Virtual Memory is exposed to a guest via vIOMMU, scalable
> IOTLB invalidation may be passed down from outside IOMMU subsystems.
> This patch adds invalidation functions that can be used for additional
> translation cache types.
>
>
Hi Jacob,
On 1/29/20 7:01 AM, Jacob Pan wrote:
> Nested translation mode is supported in VT-d 3.0 Spec.CH 3.8.
> With PASID granular translation type set to 0x11b, translation
> result from the first level(FL) also subject to a second level(SL)
> page table translation. This mode is used for SVA
Hi Jacob,
On 1/29/20 7:01 AM, Jacob Pan wrote:
> Memory type related guest PASID bind data can be grouped together for
> one simple check.
Those are flags related to memory type.
> Link:
> https://lore.kernel.org/linux-iommu/20200109095123.17ed5e6b@jacob-builder/
not sure the link is really
Hi Jacob,
On 2/3/20 11:41 PM, Jacob Pan wrote:
> On Mon, 3 Feb 2020 14:12:36 -0700
> Alex Williamson wrote:
>
>> On Mon, 3 Feb 2020 12:41:43 -0800
>> Jacob Pan wrote:
>>
>>> On Mon, 3 Feb 2020 11:27:08 -0700
>>> Alex Williamson wrote:
>>>
On Fri, 31 Jan 2020 15:51:25 -0800
Jacob
Hi Jacob,
On 1/29/20 7:02 AM, Jacob Pan wrote:
> Define a unified UAPI version to be used for compatibility
> checks between user and kernel.
>
> Signed-off-by: Liu Yi L
> Signed-off-by: Jacob Pan
> ---
> include/uapi/linux/iommu.h | 48
> ++
> 1
Hi Rob,
On 1/17/20 10:16 PM, Rob Herring wrote:
> Arm SMMUv3.2 adds support for TLB range invalidate operations.
> Support for range invalidate is determined by the RIL bit in the IDR3
> register.
>
> The range invalidate is in units of the leaf page size and operates on
> 1-32 chunks of a power
Hi Rob,
On 1/16/20 5:57 PM, Rob Herring wrote:
> On Wed, Jan 15, 2020 at 10:33 AM Auger Eric wrote:
>>
>> Hi Rob,
>>
>> On 1/15/20 3:02 PM, Rob Herring wrote:
>>> On Wed, Jan 15, 2020 at 3:21 AM Auger Eric wrote:
>>>>
>>>> Hi Rob
Hi Rob,
On 1/15/20 3:02 PM, Rob Herring wrote:
> On Wed, Jan 15, 2020 at 3:21 AM Auger Eric wrote:
>>
>> Hi Rob,
>>
>> On 1/13/20 3:39 PM, Rob Herring wrote:
>>> Arm SMMUv3.2 adds support for TLB range invalidate operations.
>>> Support for
Hi Rob,
On 1/13/20 3:39 PM, Rob Herring wrote:
> Arm SMMUv3.2 adds support for TLB range invalidate operations.
> Support for range invalidate is determined by the RIL bit in the IDR3
> register.
>
> The range invalidate is in units of the leaf page size and operates on
> 1-32 chunks of a power
Hi Jean,
On 12/19/19 5:30 PM, Jean-Philippe Brucker wrote:
> Enable PASID for PCI devices that support it. Since the SSID tables are
> allocated by arm_smmu_attach_dev(), PASID has to be enabled early enough.
> arm_smmu_dev_feature_enable() would be too late, since by that time the
> main DMA
Hi Jean,
On 12/19/19 5:30 PM, Jean-Philippe Brucker wrote:
> The SMMU can support up to 20 bits of SSID. Add a second level of page
> tables to accommodate this. Devices that support more than 1024 SSIDs now
> have a table of 1024 L1 entries (8kB), pointing to tables of 1024 context
> descriptors
Hi jean,
On 12/9/19 7:05 PM, Jean-Philippe Brucker wrote:
> At the moment, the SMMUv3 driver implements only one stage-1 or stage-2
> page directory per device. However SMMUv3 allows more than one address
> space for some devices, by providing multiple stage-1 page directories. In
> addition to
Hi Jean,
On 12/18/19 5:07 PM, Jean-Philippe Brucker wrote:
> On Tue, Dec 17, 2019 at 05:43:59PM +0100, Auger Eric wrote:
>>> -static void arm_smmu_write_ctx_desc(struct arm_smmu_device *smmu,
>>> - struct arm_smmu_s1_cfg *cfg)
>>> +stat
Hi Jean,
On 12/9/19 7:05 PM, Jean-Philippe Brucker wrote:
> Enable PASID for PCI devices that support it. Since the SSID tables are
> allocated by arm_smmu_attach_dev(), PASID has to be enabled early enough.
> arm_smmu_dev_feature_enable() would be too late, since by that time the
> main DMA
Hi Jean,
On 12/9/19 7:05 PM, Jean-Philippe Brucker wrote:
> For platform devices that support SubstreamID (SSID), firmware provides
> the number of supported SSID bits. Restrict it to what the SMMU supports
> and cache it into master->ssid_bits, which will also be used for PCI
> PASID.
>
>
Hi Jean,
On 12/9/19 7:05 PM, Jean-Philippe Brucker wrote:
> The SMMUv3 driver, which may be built without CONFIG_PCI, will soon gain
> PASID support. Partially revert commit c6e9aefbf9db ("PCI/ATS: Remove
> unused PRI and PASID stubs") to re-introduce the PASID stubs, and avoid
> adding more
Hi Jean,
On 12/9/19 7:05 PM, Jean-Philippe Brucker wrote:
> The SMMU can support up to 20 bits of SSID. Add a second level of page
> tables to accommodate this. Devices that support more than 1024 SSIDs now
> have a table of 1024 L1 entries (8kB), pointing to tables of 1024 context
> descriptors
Hi Jean,
On 12/9/19 7:05 PM, Jean-Philippe Brucker wrote:
> Second-level context descriptor tables will be allocated lazily in
> arm_smmu_write_ctx_desc(). Help with handling allocation failure by
> moving the CD write into arm_smmu_domain_finalise_s1().
nit: would rather change the title to
Hi Jean,
On 12/9/19 7:05 PM, Jean-Philippe Brucker wrote:
s/Propate/Propagate in the commit title.
> Now that we support substream IDs, initialize s1cdmax with the number of
> SSID bits supported by a master and the SMMU.
>
> Context descriptor tables are allocated once for the first master
>
Hi Jean,
On 12/17/19 4:21 PM, Jean-Philippe Brucker wrote:
> Hi Eric,
>
> On Tue, Dec 17, 2019 at 12:05:18PM +0100, Auger Eric wrote:
>>> + fwspec = dev_iommu_fwspec_get(dev);
>>> + if (!err && fwspec)
>>> + of_
Hi Jean,
On 12/9/19 7:05 PM, Jean-Philippe Brucker wrote:
> At the moment, the SMMUv3 driver implements only one stage-1 or stage-2
> page directory per device. However SMMUv3 allows more than one address
> space for some devices, by providing multiple stage-1 page directories. In
> addition to
Hi Jean,
On 12/9/19 7:05 PM, Jean-Philippe Brucker wrote:
> Support for SSID will require allocating context descriptor tables. Move
> the context descriptor allocation to separate functions.
>
> Signed-off-by: Jean-Philippe Brucker
Reviewed-by: Eric Auger
Thanks
Eric
> ---
>
Hi Jean,
On 12/9/19 7:05 PM, Jean-Philippe Brucker wrote:
> When adding SSID support to the SMMUv3 driver, we'll need to manipulate
> leaf pasid tables and context descriptors. Extract the context
> descriptor structure and introduce a new table structure.
>
> Signed-off-by: Jean-Philippe
Hi Jean,
On 12/9/19 7:05 PM, Jean-Philippe Brucker wrote:
> Named component nodes in the IORT tables describe the number of
> Substream ID bits (aka. PASID) supported by the device. Propagate this
> value to the fwspec structure in order to enable PASID for platform
> devices.
>
> Acked-by:
Hi Jean,
On 12/9/19 7:05 PM, Jean-Philippe Brucker wrote:
> For platform devices that support SubstreamID (SSID), firmware provides
> the number of supported SSID bits. Restrict it to what the SMMU supports
> and cache it into master->ssid_bits, which will also be used for PCI
> PASID.
>
>
Hi Jean,
On 12/9/19 7:05 PM, Jean-Philippe Brucker wrote:
> Since commit 518a2f1925c3 ("dma-mapping: zero memory returned from
> dma_alloc_*"), dma_alloc_* always initializes memory to zero, so there
> is no need to use dma_zalloc_* or pass the __GFP_ZERO flag anymore.
>
> The flag was
Hi,
On 12/16/19 3:24 PM, Qian Cai wrote:
>
>
>> On Nov 26, 2019, at 5:27 AM, Eric Auger wrote:
>>
>> In case the new region gets merged into another one, the nr
>> list node is freed. Checking its type while completing the
>> merge algorithm leads to a use-after-free. Use new->type
>> instead.
Hi Alex,
On 12/11/19 9:28 PM, Alex Williamson wrote:
> Commit d850c2ee5fe2 ("iommu/vt-d: Expose ISA direct mapping region via
> iommu_get_resv_regions") created a direct-mapped reserved memory region
> in order to replace the static identity mapping of the ISA address
> space, where the latter
Hi,
On 11/22/19 4:06 PM, Qian Cai wrote:
> Read files under /sys/kernel/iommu_groups/ triggers an use-after-free.
> Reverted
> the commit 4dbd258ff63e ("iommu: Revisit iommu_insert_resv_region()
> implementation") fixed the issue.
>
> /* no merge needed on elements of different types than @nr
Hi Jacob,
On 11/19/19 6:56 PM, Jacob Pan wrote:
> When setting up first level page tables for sharing with CPU, we need
> to ensure IOMMU can support no less than the levels supported by the
> CPU.
>
> It is not adequate, as in the current code, to set up 5-level paging
> in PASID entry First
alidation descriptor
> support")
> Signed-off-by: Jacob Pan
> Acked-by: Lu Baolu
R-b sent on v2
Reviewed-by: Eric Auger
Eric
> ---
> drivers/iommu/intel-svm.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/iommu/intel-svm.c
Hi Jacob,
On 11/19/19 6:56 PM, Jacob Pan wrote:
> Make use of generic IOASID code to manage PASID allocation,
> free, and lookup. Replace Intel specific code.
> IOASID allocator is inclusive for both start and end of the allocation
> range. The current code is based on IDR, which is exclusive for
Lu Baolu
I sent my R-b already on v2:
Reviewed-by: Eric Auger
Eric
> ---
> drivers/iommu/intel-pasid.c | 48
> +
> 1 file changed, 18 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/iommu/intel-pasid.c b/drivers/i
d-off-by: Jacob Pan
> Acked-by: Lu Baolu
same (v2)
Reviewed-by: Eric Auger
Eric
> ---
> drivers/iommu/intel-svm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/intel-svm.c b/drivers/iommu/intel-svm.c
> index 74df10a39dfc..e90d
Hi Jacob,
On 11/19/19 6:56 PM, Jacob Pan wrote:
> Shared Virtual Memory(SVM) is based on a collective set of hardware
> features detected at runtime. There are requirements for matching CPU
> and IOMMU capabilities.
>
> The current code checks CPU and IOMMU feature set for SVM support but
> the
Hi Jacob,
On 11/19/19 6:56 PM, Jacob Pan wrote:
> Add a check during SVM bind to ensure CPU and IOMMU hardware capabilities
> are met.
>
> Signed-off-by: Jacob Pan
> Acked-by: Lu Baolu
I sent my Rb on v2:
Reviewed-by: Eric Auger
Thanks
Eric
> ---
> drivers/iommu/intel-svm.c | 3 +++
> 1
Hi Shameer,
On 11/13/19 5:11 PM, Shameer Kolothum wrote:
> CMDQ_OP_TLBI_NH_VA requires VMID and this was missing since
> commit 1c27df1c0a82 ("iommu/arm-smmu: Use correct address mask
> for CMD_TLBI_S2_IPA"). Add it back.
>
> Fixes: 1c27df1c0a82 ("iommu/arm-smmu: Use correct address mask for
>
Hi Yi,
On 11/6/19 2:31 AM, Liu, Yi L wrote:
>> From: Alex Williamson [mailto:alex.william...@redhat.com]
>> Sent: Wednesday, November 6, 2019 6:42 AM
>> To: Liu, Yi L
>> Subject: Re: [RFC v2 1/3] vfio: VFIO_IOMMU_CACHE_INVALIDATE
>>
>> On Fri, 25 Oct 2019 11:20:40 +
>> "Liu, Yi L" wrote:
>>
Hi Shameer,
On 11/12/19 6:56 PM, Shameerali Kolothum Thodi wrote:
> Hi Eric,
>
>> -Original Message-
>> From: Shameerali Kolothum Thodi
>> Sent: 12 November 2019 14:21
>> To: 'Auger Eric' ; eric.auger@gmail.com;
>> iommu@lists.linux-foundation.org
Hi Shameer,
On 11/12/19 2:06 PM, Shameerali Kolothum Thodi wrote:
> Hi Eric,
>
>> -Original Message-----
>> From: Auger Eric [mailto:eric.au...@redhat.com]
>> Sent: 12 November 2019 11:29
>> To: Shameerali Kolothum Thodi ;
>> eric.auger@gmail.c
Hi Shameer,
On 11/12/19 12:08 PM, Shameerali Kolothum Thodi wrote:
> Hi Eric,
>
>> -Original Message-
>> From: kvmarm-boun...@lists.cs.columbia.edu
>> [mailto:kvmarm-boun...@lists.cs.columbia.edu] On Behalf Of Eric Auger
>> Sent: 11 July 2019 14:56
>> To: eric.auger@gmail.com;
Hi Jacob,
On 10/24/19 9:55 PM, Jacob Pan wrote:
> When Shared Virtual Address (SVA) is enabled for a guest OS via
> vIOMMU, we need to provide invalidation support at IOMMU API and driver
> level. This patch adds Intel VT-d specific function to implement
> iommu passdown invalidate API for shared
Hi Jacob,
On 11/8/19 11:55 PM, Jacob Pan wrote:
> On Fri, 8 Nov 2019 12:30:31 +0100
> Auger Eric wrote:
>
>> Hi Jacob,
>>
>> On 10/24/19 9:54 PM, Jacob Pan wrote:
>>> Make use of generic IOASID code to manage PASID allocation,
>>> free, and lookup
Hi Jacob,
On 10/24/19 9:54 PM, Jacob Pan wrote:
> After each setup for PASID entry, related translation caches must be flushed.
> We can combine duplicated code into one function which is less error prone.
>
> Signed-off-by: Jacob Pan
> ---
> drivers/iommu/intel-pasid.c | 48
>
Hi Jacob,
On 10/24/19 9:55 PM, Jacob Pan wrote:
> When Shared Virtual Memory is exposed to a guest via vIOMMU, scalable
> IOTLB invalidation may be passed down from outside IOMMU subsystems.
> This patch adds invalidation functions that can be used for additional
> translation cache types.
>
>
Hi Jacob,
On 10/24/19 9:55 PM, Jacob Pan wrote:
> Nested translation mode is supported in VT-d 3.0 Spec.CH 3.8.
> With PASID granular translation type set to 0x11b, translation
> result from the first level(FL) also subject to a second level(SL)
> page table translation. This mode is used for SVA
Hi Jacob,
On 10/24/19 9:54 PM, Jacob Pan wrote:
> Make use of generic IOASID code to manage PASID allocation,
> free, and lookup. Replace Intel specific code.
>
> Signed-off-by: Jacob Pan
> ---
> drivers/iommu/intel-iommu.c | 12 ++--
> drivers/iommu/intel-pasid.c | 36
Hi Jacob,
On 10/24/19 9:54 PM, Jacob Pan wrote:
> When VT-d driver runs in the guest, PASID allocation must be
> performed via virtual command interface. This patch registers a
> custom IOASID allocator which takes precedence over the default
> XArray based allocator. The resulting IOASID
Hi Jacob,
On 10/24/19 9:54 PM, Jacob Pan wrote:
> From: Lu Baolu
>
> Enabling IOMMU in a guest requires communication with the host
> driver for certain aspects. Use of PASID ID to enable Shared Virtual
> Addressing (SVA) requires managing PASID's in the host. VT-d 3.0 spec
> provides a Virtual
ecap;
> + u64 vccap;
> u32 gcmd; /* Holds TE, EAFL. Don't need SRTP, SFL, WBF */
> raw_spinlock_t register_lock; /* protect register handling */
> int seq_id; /* sequence id of the iommu */
>
with DMA_VCS_PAS's move i
Hi,
On 10/2/19 9:42 PM, Jacob Pan wrote:
> This set consists of IOMMU APIs to support SVA in the guest, a.k.a nested
> SVA. As the complete SVA support is complex, we break down the enabling
> effort into three stages:
> 1. PCI device direct assignment
> 2. Fault handling, especially page request
Hi Will,
As a follow-up of the VFIO/IOMMU/PCI "Dual Stage SMMUv3 Status"
session, please find some further justifications about the
SMMUv3 nested stage enablement series.
In the text below, I only talk about use cases featuring
VFIO assigned devices where the physical IOMMU is actually
involved.
Hi Thierry,
On 8/29/19 1:17 PM, Thierry Reding wrote:
> From: Thierry Reding
>
> Most IOMMU drivers only need to free the memory allocated for each
> reserved region. Instead of open-coding the loop to do this in each
> driver, extract the code into a common function that can be used by
> all
Hi Christoph,
On 8/6/19 9:32 AM, Christoph Hellwig wrote:
> A couple nitpicks below:
>
> On Thu, Aug 01, 2019 at 05:59:46PM +0200, Eric Auger wrote:
>> - * The new element is sorted by address with respect to the other
>> - * regions of the same type. In case it overlaps with another
>> - *
Hi Shameer,
On 8/1/19 3:46 PM, Shameerali Kolothum Thodi wrote:
> Hi Eric,
>
>> -Original Message-
>> From: Eric Auger [mailto:eric.au...@redhat.com]
>> Sent: 30 July 2019 15:01
>> To: eric.auger@gmail.com; eric.au...@redhat.com; j...@8bytes.org;
>> iommu@lists.linux-foundation.org;
Hi Shameer,
On 7/23/19 6:06 PM, Shameer Kolothum wrote:
> Get a copy of iova list on _group_detach and try to update the list.
> On success replace the current one with the copy. Leave the list as
> it is if update fails.
>
> Signed-off-by: Shameer Kolothum
Reviewed-by: Eric Auger
Thanks
Hi Shameer,
On 7/23/19 6:06 PM, Shameer Kolothum wrote:
> This introduces an iova list that is valid for dma mappings. Make
> sure the new iommu aperture window doesn't conflict with the current
> one or with any existing dma mappings during attach.
>
> Signed-off-by: Shameer Kolothum
Hi Shameer,
On 7/23/19 6:06 PM, Shameer Kolothum wrote:
> This retrieves the reserved regions associated with dev group and
> checks for conflicts with any existing dma mappings. Also update
> the iova list excluding the reserved regions.
>
> Reserved regions with type
Hi Christoph, Michael,
On 7/25/19 3:04 PM, Christoph Hellwig wrote:
> On Thu, Jul 25, 2019 at 01:53:49PM +0200, Auger Eric wrote:
>> I am confused: if vring_use_dma_api() returns false if the dma_mask is
>> unset (ie. vring_use_dma_api() returns false), the virtio
Hi,
On 7/23/19 5:38 PM, Christoph Hellwig wrote:
> On Mon, Jul 22, 2019 at 04:36:09PM +0100, Robin Murphy wrote:
>>> diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
>>> index c8be1c4f5b55..37c143971211 100644
>>> --- a/drivers/virtio/virtio_ring.c
>>> +++
Hi Christoph,
On 7/22/19 6:51 PM, Eric Auger wrote:
> We currently have cases where the dma_addressing_limited() gets
> called with dma_mask unset. This causes a NULL pointer dereference.
>
> Use dma_get_mask() accessor to prevent the crash.
>
> Fixes: b866455423e0 ("dma-mapping: add a
Hi Christoph,
On 7/22/19 5:26 PM, Christoph Hellwig wrote:
>> static inline bool dma_addressing_limited(struct device *dev)
>> {
>> -return min_not_zero(*dev->dma_mask, dev->bus_dma_mask) <
>> -dma_get_required_mask(dev);
>> +return WARN_ON_ONCE(!dev->dma_mask) ? false :
>>
201 - 300 of 619 matches
Mail list logo
