There's no need for the non-dma_ops path to keep track of IOVAs. The
whole point of the non-dma_ops path is that it allows the IOVAs to be
handled separately. The IOVA handling code removed in this patch is
pointless.
Signed-off-by: Tom Murphy
---
drivers/iommu/intel-iommu.c | 97
> -Original Message-
> From: Jean-Philippe Brucker
> Sent: Wednesday, April 1, 2020 9:20 PM
> To: Robin Murphy
> Cc: Bharat Bhushan ; j...@8bytes.org;
> m...@redhat.com; jasow...@redhat.com; virtualization@lists.linux-
> foundation.org; iommu@lists.linux-foundation.org;
>
> From: Jacob Pan
> Sent: Wednesday, April 1, 2020 11:48 PM
>
> On Sat, 28 Mar 2020 10:22:41 +
> "Tian, Kevin" wrote:
>
> > > From: Jacob Pan
> > > Sent: Saturday, March 21, 2020 7:28 AM
> > >
> > > When VT-d driver runs in the guest, PASID allocation must be
> > > performed via virtual
> From: Liu, Yi L
> Sent: Wednesday, April 1, 2020 5:13 PM
>
> > From: Tian, Kevin
> > Sent: Monday, March 30, 2020 8:46 PM
> > Subject: RE: [PATCH v1 6/8] vfio/type1: Bind guest page tables to host
> >
> > > From: Liu, Yi L
> > > Sent: Sunday, March 22, 2020 8:32 PM
> > >
> > > From: Liu Yi L
On Wed, 1 Apr 2020 16:03:01 +0200
Jean-Philippe Brucker wrote:
> Hi Jacob,
>
> On Wed, Mar 25, 2020 at 10:55:21AM -0700, Jacob Pan wrote:
> > IOASID was introduced in v5.5 as a generic kernel allocator service
> > for both PCIe Process Address Space ID (PASID) and ARM SMMU's Sub
> > Stream ID.
On 2/2/18 10:59 AM, Eric Dumazet wrote:
> On Fri, Feb 2, 2018 at 10:53 AM, Christoph Hellwig wrote:
>> I've got patches pending to replace all that code with
>> dma_direct_alloc, which will do the right thing. They were
>> submitted for 4.16, and I will resend them after -rc1.
>
> I see,
Hi Jean,
On Wed, 1 Apr 2020 15:45:52 +0200
Jean-Philippe Brucker wrote:
> On Wed, Mar 25, 2020 at 10:55:22AM -0700, Jacob Pan wrote:
> > IOASID is a limited system-wide resource that can be allocated at
> > runtime. This limitation can be enumerated during boot. For
> > example, on x86
On Wed, 1 Apr 2020 11:27:24 +0100
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
On Wed, 1 Apr 2020 15:55:25 +0200
Jean-Philippe Brucker wrote:
> On Wed, Mar 25, 2020 at 10:55:27AM -0700, Jacob Pan wrote:
> > The current ioasid_alloc function takes a token/ioasid_set then
> > record it on the IOASID being allocated. There is no alloc/free on
> > the ioasid_set.
> >
> > With
On Sun, 29 Mar 2020 13:35:15 +0200
Auger Eric wrote:
> 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
On Tue, 31 Mar 2020 03:43:39 +
"Tian, Kevin" wrote:
> > > > struct intel_svm_dev {
> > > > @@ -698,9 +700,13 @@ struct intel_svm_dev {
> > > > struct intel_svm {
> > > > struct mmu_notifier notifier;
> > > > struct mm_struct *mm;
> > > > +
> > > > struct intel_iommu
On Wed, 1 Apr 2020 09:32:37 +0200
Auger Eric wrote:
> >> devtlb
> >> descriptor, that is why Eric suggests {0, 0, 1}.
> >
> > I think it should be {0, 0, 1} :-) addr field and S field are must,
> > pasid field depends on G bit.
>
> On my side, I understood from the spec that addr/S are
On Wed, 1 Apr 2020 06:57:42 +
"Liu, Yi L" wrote:
> > From: Tian, Kevin
> > Sent: Wednesday, April 1, 2020 2:24 PM
> > To: Jacob Pan
> > Subject: RE: [PATCH V10 08/11] iommu/vt-d: Add svm/sva invalidate
> > function
> > > From: Jacob Pan
> > > Sent: Wednesday, April 1, 2020 2:14 AM
> > >
On Wed, Apr 01, 2020 at 02:00:13PM +0100, Robin Murphy wrote:
> On 2020-04-01 12:38 pm, Bharat Bhushan wrote:
> > Different endpoint can support different page size, probe
> > endpoint if it supports specific page size otherwise use
> > global page sizes.
> >
> > Signed-off-by: Bharat Bhushan
>
On Sat, 28 Mar 2020 10:22:41 +
"Tian, Kevin" wrote:
> > From: Jacob Pan
> > Sent: Saturday, March 21, 2020 7:28 AM
> >
> > 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
Hi Jacob,
On Wed, Mar 25, 2020 at 10:55:21AM -0700, Jacob Pan wrote:
> IOASID was introduced in v5.5 as a generic kernel allocator service for
> both PCIe Process Address Space ID (PASID) and ARM SMMU's Sub Stream
> ID. In addition to basic ID allocation, ioasid_set was introduced as a
> token
On Wed, Mar 25, 2020 at 10:55:29AM -0700, Jacob Pan wrote:
> IOASID users fit into the publisher-subscriber pattern, a system wide
> blocking notifier chain can be used to inform subscribers of state
> changes. Notifier mechanism also abstracts publisher from knowing the
> private context each
On Wed, Mar 25, 2020 at 10:55:28AM -0700, Jacob Pan wrote:
> Each IOASID or set could have multiple users with its own HW context
> to maintain. Often times access to the HW context requires thread context.
> For example, consumers of IOASIDs can register notification blocks to
> sync up its
On Wed, Mar 25, 2020 at 10:55:27AM -0700, Jacob Pan wrote:
> The current ioasid_alloc function takes a token/ioasid_set then record it
> on the IOASID being allocated. There is no alloc/free on the ioasid_set.
>
> With the IOASID set APIs, callers must allocate an ioasid_set before
> allocate
On Wed, Mar 25, 2020 at 10:55:26AM -0700, Jacob Pan wrote:
> Bare metal SVA allocates IOASIDs for native process addresses. This
> should be separated from VM allocated IOASIDs thus under its own set.
>
> This patch creates a system IOASID set with its quota set to PID_MAX.
> This is a reasonable
On Wed, Mar 25, 2020 at 10:55:24AM -0700, Jacob Pan wrote:
> IOASID set defines a group of IDs that share the same token. The
> ioasid_set concept helps to do permission checking among users as in the
> current code.
>
> With guest SVA usage, each VM has its own IOASID set. More
> functionalities
On Wed, Mar 25, 2020 at 10:55:22AM -0700, Jacob Pan wrote:
> IOASID is a limited system-wide resource that can be allocated at
> runtime. This limitation can be enumerated during boot. For example, on
> x86 platforms, PCI Process Address Space ID (PASID) allocation uses
> IOASID service. The
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 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.
Regards,
Yi Liu
> From: Eric Auger
> Sent: Saturday, March 21, 2020 12:19 AM
> To: eric.auger@gmail.com; eric.au...@redhat.com;
Hi Eric,
> From: Auger Eric
> Sent: Wednesday, April 1, 2020 5:41 PM
> To: Liu, Yi L ; alex.william...@redhat.com
> Subject: Re: [PATCH v1 3/8] vfio/type1: Report PASID alloc/free support to
> userspace
>
> Yi,
> On 3/22/20 1:32 PM, Liu, Yi L wrote:
> > From: Liu Yi L
> >
> > This patch
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
>>
>> Hi Yi,
>> On 3/22/20 1:32 PM, Liu,
On 2020-04-01 12:38 pm, Bharat Bhushan wrote:
Different endpoint can support different page size, probe
endpoint if it supports specific page size otherwise use
global page sizes.
Signed-off-by: Bharat Bhushan
---
drivers/iommu/virtio-iommu.c | 33 +++
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
>
> Hi Yi,
> On 3/22/20 1:32 PM, Liu, Yi L wrote:
> > From: Liu Yi L
> >
> > VFIO exposes
Hi Jörg,
Thanks for your review, I'll fix the issues you pointed out and I left
out.
On Mon, Mar 02, 2020 at 04:36:06PM +0100, Joerg Roedel wrote:
> On Thu, Feb 20, 2020 at 07:15:14PM +0100, Maxime Ripard wrote:
> > +struct sun50i_iommu_domain {
> > + struct iommu_domain domain;
> > +
> > +
Different endpoint can support different page size, probe
endpoint if it supports specific page size otherwise use
global page sizes.
Signed-off-by: Bharat Bhushan
---
drivers/iommu/virtio-iommu.c | 33 +++
include/uapi/linux/virtio_iommu.h | 7 +++
2 files
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.
This fixes VFIO with a platform device on the Calxeda Midway
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:
> From: Tian, Kevin
> Sent: Monday, March 30, 2020 8:46 PM
> Subject: RE: [PATCH v1 6/8] vfio/type1: Bind guest page tables to host
>
> > From: Liu, Yi L
> > Sent: Sunday, March 22, 2020 8:32 PM
> >
> > From: Liu Yi L
> >
> > VFIO_TYPE1_NESTING_IOMMU is an IOMMU type which is backed by
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
> From: Tian, Kevin
> Sent: Wednesday, April 1, 2020 4:09 PM
> Subject: RE: [PATCH v1 5/8] vfio/type1: Report 1st-level/stage-1 format to
> userspace
>
> > From: Liu, Yi L
> > Sent: Wednesday, April 1, 2020 4:07 PM
> >
> > > From: Tian, Kevin
> > > Sent: Wednesday, April 1, 2020 3:56 PM
> > >
> From: Liu, Yi L
> Sent: Wednesday, April 1, 2020 4:07 PM
>
> > From: Tian, Kevin
> > Sent: Wednesday, April 1, 2020 3:56 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
> >
> > > From: Liu, Yi L
>
> From: Tian, Kevin
> Sent: Wednesday, April 1, 2020 3:56 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
>
> > From: Liu, Yi L
> > Sent: Wednesday, April 1, 2020 3:38 PM
> >
> > > From: Tian, Kevin
> >
> From: Liu, Yi L
> Sent: Wednesday, April 1, 2020 3:38 PM
>
> > From: Tian, Kevin
> > Sent: Monday, March 30, 2020 7:49 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
> >
> > > From: Liu, Yi L
>
> From: Tian, Kevin
> Sent: Monday, March 30, 2020 9:19 PM
> To: Liu, Yi L ; alex.william...@redhat.com;
> Subject: RE: [PATCH v1 8/8] vfio/type1: Add vSVA support for IOMMU-backed
> mdevs
>
> > From: Liu, Yi L
> > Sent: Sunday, March 22, 2020 8:32 PM
> >
> > From: Liu Yi L
> >
> > Recent
> From: Tian, Kevin
> Sent: Monday, March 30, 2020 8:58 PM
> To: Liu, Yi L ; alex.william...@redhat.com;
> Subject: RE: [PATCH v1 7/8] vfio/type1: Add VFIO_IOMMU_CACHE_INVALIDATE
>
> > From: Liu, Yi L
> > Sent: Sunday, March 22, 2020 8:32 PM
> >
> > From: Liu Yi L
> >
> > For VFIO IOMMUs with
> From: Tian, Kevin
> Sent: Monday, March 30, 2020 5:44 PM
> To: Liu, Yi L ; alex.william...@redhat.com;
> Subject: RE: [PATCH v1 3/8] vfio/type1: Report PASID alloc/free support to
> userspace
>
> > From: Liu, Yi L
> > Sent: Sunday, March 22, 2020 8:32 PM
> >
> > From: Liu Yi L
> >
> > This
> From: Tian, Kevin
> Sent: Monday, March 30, 2020 7:49 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
>
> > From: Liu, Yi L
> > Sent: Sunday, March 22, 2020 8:32 PM
> >
> > From: Liu Yi L
> >
> > VFIO
Hi,
On 4/1/20 9:13 AM, Liu, Yi L wrote:
>> From: Tian, Kevin
>> Sent: Wednesday, April 1, 2020 2:30 PM
>> To: Jacob Pan
>> Subject: RE: [PATCH V10 08/11] iommu/vt-d: Add svm/sva invalidate function
>>
>>> From: Jacob Pan
>>> Sent: Wednesday, April 1, 2020 4:58 AM
>>>
>>> On Tue, 31 Mar 2020
> From: Tian, Kevin
> Sent: Wednesday, April 1, 2020 2:30 PM
> To: Jacob Pan
> Subject: RE: [PATCH V10 08/11] iommu/vt-d: Add svm/sva invalidate function
>
> > From: Jacob Pan
> > Sent: Wednesday, April 1, 2020 4:58 AM
> >
> > On Tue, 31 Mar 2020 02:49:21 +
> > "Tian, Kevin" wrote:
> >
>
> From: Tian, Kevin
> Sent: Wednesday, April 1, 2020 2:24 PM
> To: Jacob Pan
> Subject: RE: [PATCH V10 08/11] iommu/vt-d: Add svm/sva invalidate function
>
> > From: Jacob Pan
> > Sent: Wednesday, April 1, 2020 2:14 AM
> >
> > On Sat, 28 Mar 2020 10:01:42 +
> > "Tian, Kevin" wrote:
> >
>
> From: Jacob Pan
> Sent: Wednesday, April 1, 2020 5:08 AM
>
> On Tue, 31 Mar 2020 03:34:22 +
> "Tian, Kevin" wrote:
>
> > > From: Auger Eric
> > > Sent: Monday, March 30, 2020 12:05 AM
> > >
> > > On 3/28/20 11:01 AM, Tian, Kevin wrote:
> > > >> From: Jacob Pan
> > > >> Sent: Saturday,
> From: Jacob Pan
> Sent: Wednesday, April 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,
> > >
> > > On 3/28/20 11:01 AM, Tian, Kevin wrote:
> > > >> From: Jacob Pan
> > > >>
> From: Jacob Pan
> Sent: Wednesday, April 1, 2020 2:14 AM
>
> On Sat, 28 Mar 2020 10:01:42 +
> "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
48 matches
Mail list logo
