> From: Leon Romanovsky
> Sent: Wednesday, June 9, 2021 5:02 PM
>
> On Mon, Jun 07, 2021 at 02:58:18AM +, Tian, Kevin wrote:
> > Hi, all,
>
> <...>
>
> > (Remaining opens in v1)
>
> <...>
>
> > - Device-centric (Ja
> From: Eric Auger
> Sent: Wednesday, June 9, 2021 4:15 PM
>
> Hi Kevin,
>
> On 6/7/21 4:58 AM, Tian, Kevin wrote:
> > Hi, all,
> >
> > We plan to work on v2 now, given many good comments already received
> > and substantial changes envisioned. This
> From: David Gibson
> Sent: Tuesday, June 8, 2021 8:50 AM
>
> On Thu, Jun 03, 2021 at 06:49:20AM +, Tian, Kevin wrote:
> > > From: David Gibson
> > > Sent: Thursday, June 3, 2021 1:09 PM
> > [...]
> > > > > In this way the SW mode is the
> From: Alex Williamson
> Sent: Wednesday, June 9, 2021 2:47 AM
>
> On Tue, 8 Jun 2021 15:44:26 +0200
> Paolo Bonzini wrote:
>
> > On 08/06/21 15:15, Jason Gunthorpe wrote:
> > > On Tue, Jun 08, 2021 at 09:56:09AM +0200, Paolo Bonzini wrote:
> > >
> > Alternatively you can add a
> From: Paolo Bonzini
> Sent: Saturday, June 5, 2021 2:22 PM
>
> On 04/06/21 19:22, Jason Gunthorpe wrote:
> > 4) The KVM interface is the very simple enable/disable WBINVD.
> > Possessing a FD that can do IOMMU_EXECUTE_WBINVD is required
> > to enable WBINVD at KVM.
>
> The KVM
> From: Alex Williamson
> Sent: Saturday, June 5, 2021 5:29 AM
>
> On Fri, 4 Jun 2021 14:22:07 -0300
> Jason Gunthorpe wrote:
>
> > On Fri, Jun 04, 2021 at 06:10:51PM +0200, Paolo Bonzini wrote:
> > > On 04/06/21 18:03, Jason Gunthorpe wrote:
> > > > On Fri, Jun 04, 2021 at 05:57:19PM +0200,
Hi, all,
We plan to work on v2 now, given many good comments already received
and substantial changes envisioned. This is a very complex topic with
many sub-threads being discussed. To ensure that I didn't miss valuable
suggestions (and also keep everyone on the same page), here I'd like to
> From: Jason Gunthorpe
> Sent: Friday, June 4, 2021 8:34 PM
>
> On Fri, Jun 04, 2021 at 06:08:28AM +, Tian, Kevin wrote:
>
> > In Qemu case the problem is that it doesn't know the list of devices
> > that will be attached to an IOASID when it's created. This is
> From: Jason Gunthorpe
> Sent: Friday, June 4, 2021 8:09 PM
>
> On Fri, Jun 04, 2021 at 06:37:26AM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Thursday, June 3, 2021 9:05 PM
> > >
> > > > >
> > > > >
> From: Alex Williamson
> Sent: Friday, June 4, 2021 4:42 AM
>
> > 'qemu --allow-no-snoop' makes more sense to me
>
> I'd be tempted to attach it to the -device vfio-pci option, it's
> specific drivers for specific devices that are going to want this and
> those devices may not be permanently
> From: Jean-Philippe Brucker
> Sent: Friday, June 4, 2021 4:18 PM
>
> On Wed, Jun 02, 2021 at 01:25:00AM +, Tian, Kevin wrote:
> > > > This implies that VFIO_BOUND_IOASID will be extended to allow user
> > > > specify a device label. This
> From: Alex Williamson
> Sent: Friday, June 4, 2021 5:44 AM
>
> > Based on that observation we can say as soon as the user wants to use
> > an IOMMU that does not support DMA_PTE_SNP in the guest we can still
> > share the IO page table with IOMMUs that do support DMA_PTE_SNP.
page table
> From: Jason Gunthorpe
> Sent: Thursday, June 3, 2021 8:41 PM
>
> > When discussing I/O page fault support in another thread, the consensus
> > is that an device handle will be registered (by user) or allocated (return
> > to user) in /dev/ioasid when binding the device to ioasid fd. From this
> From: Jason Gunthorpe
> Sent: Thursday, June 3, 2021 9:05 PM
>
> > >
> > > 3) Device accepts any PASIDs from the guest. No
> > >vPASID/pPASID translation is possible. (classic vfio_pci)
> > > 4) Device accepts any PASID from the guest and has an
> > >internal vPASID/pPASID translation
> From: Jason Gunthorpe
> Sent: Thursday, June 3, 2021 8:46 PM
>
> On Thu, Jun 03, 2021 at 04:26:08PM +1000, David Gibson wrote:
>
> > > There are global properties in the /dev/iommu FD, like what devices
> > > are part of it, that are important for group security operations. This
> > > becomes
> From: Jason Gunthorpe
> Sent: Thursday, June 3, 2021 8:11 PM
>
> On Thu, Jun 03, 2021 at 03:45:09PM +1000, David Gibson wrote:
> > On Wed, Jun 02, 2021 at 01:58:38PM -0300, Jason Gunthorpe wrote:
> > > On Wed, Jun 02, 2021 at 04:48:35PM +1000, David Gibson wrote:
> > > > > > /* Bind guest
> From: Jason Gunthorpe
> Sent: Thursday, June 3, 2021 7:47 PM
>
> On Thu, Jun 03, 2021 at 06:49:20AM +, Tian, Kevin wrote:
> > > From: David Gibson
> > > Sent: Thursday, June 3, 2021 1:09 PM
> > [...]
> > > > > In this way th
> From: David Gibson
> Sent: Wednesday, June 2, 2021 2:15 PM
>
[...]
> >
> > /*
> > * Get information about an I/O address space
> > *
> > * Supported capabilities:
> > * - VFIO type1 map/unmap;
> > * - pgtable/pasid_table binding
> > * - hardware nesting vs. software nesting;
> >
> From: David Gibson
> Sent: Wednesday, June 2, 2021 2:15 PM
>
[...]
> > An I/O address space takes effect in the IOMMU only after it is attached
> > to a device. The device in the /dev/ioasid context always refers to a
> > physical one or 'pdev' (PF or VF).
>
> What you mean by "physical"
> From: David Gibson
> Sent: Thursday, June 3, 2021 1:09 PM
[...]
> > > In this way the SW mode is the same as a HW mode with an infinite
> > > cache.
> > >
> > > The collaposed shadow page table is really just a cache.
> > >
> >
> > OK. One additional thing is that we may need a 'caching_mode"
>
> From: Jason Gunthorpe
> Sent: Saturday, May 29, 2021 7:37 AM
>
> On Thu, May 27, 2021 at 07:58:12AM +, Tian, Kevin wrote:
>
> > 2.1. /dev/ioasid uAPI
> > +
> >
> > /*
> > * Check whether an uAPI extension is supported.
>
> From: Alex Williamson
> Sent: Thursday, June 3, 2021 12:15 PM
>
> On Thu, 3 Jun 2021 03:22:27 +0000
> "Tian, Kevin" wrote:
>
> > > From: Alex Williamson
> > > Sent: Thursday, June 3, 2021 10:51 AM
> > >
> > >
> From: Alex Williamson
> Sent: Thursday, June 3, 2021 10:51 AM
>
> On Wed, 2 Jun 2021 19:45:36 -0300
> Jason Gunthorpe wrote:
>
> > On Wed, Jun 02, 2021 at 02:37:34PM -0600, Alex Williamson wrote:
> >
> > > Right. I don't follow where you're jumping to relaying DMA_PTE_SNP
> > > from the
> From: Jason Gunthorpe
> Sent: Thursday, June 3, 2021 1:20 AM
>
[...]
> > I wonder if there's a way to model this using a nested AS rather than
> > requiring special operations. e.g.
> >
> > 'prereg' IOAS
> > |
> > \- 'rid' IOAS
> >|
> >\- 'pasid' IOAS (maybe)
> >
>
> From: Jason Gunthorpe
> Sent: Thursday, June 3, 2021 12:59 AM
>
> On Wed, Jun 02, 2021 at 04:48:35PM +1000, David Gibson wrote:
> > > > /* Bind guest I/O page table */
> > > > bind_data = {
> > > > .ioasid = gva_ioasid;
> > > > .addr =
> From: Jason Gunthorpe
> Sent: Thursday, June 3, 2021 12:17 AM
>
[...]
> > > If there are no hypervisor traps (does this exist?) then there is no
> > > way to involve the hypervisor here and the child IOASID should simply
> > > be a pointer to the guest's data structure that describes binding.
> From: Jason Gunthorpe
> Sent: Thursday, June 3, 2021 12:09 AM
>
> On Wed, Jun 02, 2021 at 01:33:22AM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Wednesday, June 2, 2021 1:42 AM
> > >
> > > On Tue, Jun 01, 2021 at 08:10:14AM
> From: Alex Williamson
> Sent: Wednesday, June 2, 2021 6:22 AM
>
> On Tue, 1 Jun 2021 07:01:57 +0000
> "Tian, Kevin" wrote:
> >
> > I summarized five opens here, about:
> >
> > 1) Finalizing the name to replace /dev/ioasid;
> > 2) Whethe
> From: Jason Gunthorpe
> Sent: Wednesday, June 2, 2021 1:57 AM
>
> On Tue, Jun 01, 2021 at 08:38:00AM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Saturday, May 29, 2021 3:59 AM
> > >
> > > On Thu, May 27, 2021 at 07:58:12AM
> From: Jason Gunthorpe
> Sent: Wednesday, June 2, 2021 1:42 AM
>
> On Tue, Jun 01, 2021 at 08:10:14AM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Saturday, May 29, 2021 1:36 AM
> > >
> > > On Thu, May 27, 2021 at 07:58:12A
> From: Jason Gunthorpe
> Sent: Wednesday, June 2, 2021 4:29 AM
>
> On Tue, Jun 01, 2021 at 07:01:57AM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Saturday, May 29, 2021 4:03 AM
> > >
> > > On Thu, May 27, 2021 at 07:58:12
> From: Jason Gunthorpe
> Sent: Saturday, May 29, 2021 3:59 AM
>
> On Thu, May 27, 2021 at 07:58:12AM +, Tian, Kevin wrote:
> >
> > 5. Use Cases and Flows
> >
> > Here assume VFIO will support a new model where every bound device
> > is explicitly l
> From: Jason Gunthorpe
> Sent: Saturday, May 29, 2021 1:36 AM
>
> On Thu, May 27, 2021 at 07:58:12AM +, Tian, Kevin wrote:
>
> > IOASID nesting can be implemented in two ways: hardware nesting and
> > software nesting. With hardware support the child and
> From: Jean-Philippe Brucker
> Sent: Saturday, May 29, 2021 12:23 AM
> >
> > IOASID nesting can be implemented in two ways: hardware nesting and
> > software nesting. With hardware support the child and parent I/O page
> > tables are walked consecutively by the IOMMU to form a nested
> From: Jason Gunthorpe
> Sent: Saturday, May 29, 2021 4:03 AM
>
> On Thu, May 27, 2021 at 07:58:12AM +, Tian, Kevin wrote:
> > /dev/ioasid provides an unified interface for managing I/O page tables for
> > devices assigned to userspace. Device passthrough framework
> From: Jason Wang
> Sent: Tuesday, June 1, 2021 2:07 PM
>
> 在 2021/6/1 下午1:42, Tian, Kevin 写道:
> >> From: Jason Wang
> >> Sent: Tuesday, June 1, 2021 1:30 PM
> >>
> >> 在 2021/6/1 下午1:23, Lu Baolu 写道:
> >>> Hi Jason W,
> >>&g
> From: Jason Wang
> Sent: Tuesday, June 1, 2021 1:30 PM
>
> 在 2021/6/1 下午1:23, Lu Baolu 写道:
> > Hi Jason W,
> >
> > On 6/1/21 1:08 PM, Jason Wang wrote:
> 2) If yes, what's the reason for not simply use the fd opened from
> /dev/ioas. (This is the question that is not answered) and
/dev/ioasid provides an unified interface for managing I/O page tables for
devices assigned to userspace. Device passthrough frameworks (VFIO, vDPA,
etc.) are expected to use this interface instead of creating their own logic to
isolate untrusted device DMAs initiated by userspace.
This
> From: Jason Gunthorpe
> Sent: Thursday, May 20, 2021 2:07 AM
>
> On Wed, May 19, 2021 at 04:23:21PM +0100, Robin Murphy wrote:
> > On 2021-05-17 16:35, Joerg Roedel wrote:
> > > On Mon, May 17, 2021 at 10:35:00AM -0300, Jason Gunthorpe wrote:
> > > > Well, I'm sorry, but there is a huge other
> From: Jason Gunthorpe
> Sent: Friday, May 14, 2021 9:40 PM
>
> On Fri, May 14, 2021 at 01:17:23PM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Thursday, May 13, 2021 8:01 PM
> > >
> > > On Thu, May 13, 2021 at 03:28:52AM
> From: Jason Gunthorpe
> Sent: Thursday, May 13, 2021 8:01 PM
>
> On Thu, May 13, 2021 at 03:28:52AM +, Tian, Kevin wrote:
>
> > Are you specially concerned about this iommu_device hack which
> > directly connects mdev_device to iommu layer or the entire removed
> From: Jason Gunthorpe
> Sent: Friday, May 14, 2021 8:19 PM
>
> On Fri, May 14, 2021 at 06:54:16AM +, Tian, Kevin wrote:
> > > From: Tian, Kevin
> > > Sent: Friday, May 14, 2021 2:28 PM
> > >
> > > > From: Jason Gunthorpe
> > > &
> From: Tian, Kevin
> Sent: Friday, May 14, 2021 2:28 PM
>
> > From: Jason Gunthorpe
> > Sent: Thursday, May 13, 2021 8:01 PM
> >
> > On Thu, May 13, 2021 at 03:28:52AM +, Tian, Kevin wrote:
> >
> > > Are you specially concerned about this
> From: Jason Gunthorpe
> Sent: Thursday, May 13, 2021 8:01 PM
>
> On Thu, May 13, 2021 at 03:28:52AM +, Tian, Kevin wrote:
>
> > Are you specially concerned about this iommu_device hack which
> > directly connects mdev_device to iommu layer or the entire removed
> From: David Gibson
> Sent: Thursday, May 13, 2021 2:01 PM
> >
> > But this definitely all becomes HW specific.
> >
> > For instance I want to have an ARM vIOMMU driver it needs to do some
> >
> > ret = ioctl(ioasid_fd, CREATE_NESTED_IOASID, [page table format is
> ARMvXXX])
> > if (ret ==
> From: Jason Gunthorpe
> Sent: Monday, May 10, 2021 11:55 PM
>
> On Mon, May 10, 2021 at 08:54:02AM +0200, Christoph Hellwig wrote:
> > The iommu_device field in struct mdev_device has never been used
> > since it was added more than 2 years ago.
> >
> > Signed-off-by: Christoph Hellwig
> >
> From: Lu Baolu
> Sent: Wednesday, May 12, 2021 7:31 PM
>
> Hi Kevin,
>
> On 5/12/21 4:30 PM, Tian, Kevin wrote:
> >> From: Lu Baolu
> >> Sent: Wednesday, May 12, 2021 3:04 PM
> >>
> >> Current VT-d implementation supports nested
> From: Lu Baolu
> Sent: Wednesday, May 12, 2021 3:04 PM
>
> Current VT-d implementation supports nested translation only if all
> underlying IOMMUs support the nested capability. This is unnecessary
> as the upper layer is allowed to create different containers and set
> them with different
> From: Jason Gunthorpe
> Sent: Wednesday, May 12, 2021 1:37 AM
>
> On Tue, May 11, 2021 at 02:56:05PM +0800, Lu Baolu wrote:
>
> > > After my next series the mdev drivers will have direct access to
> > > the vfio_device. So an alternative to using the struct device, or
> > > adding
> From: Jason Gunthorpe
> Sent: Wednesday, May 12, 2021 8:25 AM
>
> On Wed, May 12, 2021 at 12:21:24AM +, Tian, Kevin wrote:
>
> > > Basically each RID knows based on its kernel drivers if it is a local
> > > or global RID and the ioasid knob can further f
> From: Jason Gunthorpe
> Sent: Wednesday, May 12, 2021 7:40 AM
>
> On Tue, May 11, 2021 at 10:51:40PM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Tuesday, May 11, 2021 10:39 PM
> > >
> > > On Tue, May 11, 2021 at 09:10:03AM
> From: Liu Yi L
> Sent: Tuesday, May 11, 2021 9:25 PM
>
> On Tue, 11 May 2021 09:10:03 +, Tian, Kevin wrote:
>
> > > From: Jason Gunthorpe
> > > Sent: Monday, May 10, 2021 8:37 PM
> > >
> > [...]
> > > > gPASID!=hPASID has a pro
> From: Jason Gunthorpe
> Sent: Tuesday, May 11, 2021 10:39 PM
>
> On Tue, May 11, 2021 at 09:10:03AM +, Tian, Kevin wrote:
>
> > 3) SRIOV, ENQCMD (Intel):
> > - "PASID global" with host-allocated PASIDs;
> > - PASID table managed by ho
> From: Jason Gunthorpe
> Sent: Monday, May 10, 2021 8:37 PM
>
[...]
> > gPASID!=hPASID has a problem when assigning a physical device which
> > supports both shared work queue (ENQCMD with PASID in MSR)
> > and dedicated work queue (PASID in device register) to a guest
> > process which is
> From: Raj, Ashok
> Sent: Friday, May 7, 2021 12:33 AM
>
> > Basically it means when the guest's top level IOASID is created for
> > nesting that IOASID claims all PASID's on the RID and excludes any
> > PASID IOASIDs from existing on the RID now or in future.
>
> The way to look at it this is
> From: Alex Williamson
> Sent: Saturday, May 8, 2021 1:06 AM
>
> > > Those are the main ones I can think of. It is nice to have a simple
> > > map/unmap interface, I'd hope that a new /dev/ioasid interface wouldn't
> > > raise the barrier to entry too high, but the user needs to have the
> > >
> From: Jason Gunthorpe
> Sent: Saturday, May 8, 2021 1:11 AM
>
> On Fri, May 07, 2021 at 11:06:14AM -0600, Alex Williamson wrote:
>
> > We had tossed around an idea of a super-container with vfio, it's maybe
> > something we'd want to incorporate into this design. For instance, if
> > memory
> From: Jason Gunthorpe
> Sent: Thursday, April 29, 2021 4:46 AM
>
> > > I think the name IOASID is fine for the uAPI, the kernel version can
> > > be called ioasid_id or something.
> >
> > ioasid is already an id and then ioasid_id just adds confusion. Another
> > point is that ioasid is
> From: Jason Gunthorpe
> Sent: Wednesday, May 5, 2021 1:13 AM
>
> On Wed, Apr 28, 2021 at 06:58:19AM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Wednesday, April 28, 2021 1:12 AM
> > >
> > [...]
> > > > As Alex s
> From: Alex Williamson
> Sent: Wednesday, April 28, 2021 11:06 PM
>
> On Wed, 28 Apr 2021 06:34:11 +0000
> "Tian, Kevin" wrote:
>
> > > From: Jason Gunthorpe
> > > Sent: Monday, April 26, 2021 8:38 PM
> > >
> > [...]
> >
> From: Jason Gunthorpe
> Sent: Wednesday, April 28, 2021 1:12 AM
>
[...]
> One option is VFIO can keep its group FD but nothing else will have
> anthing like it. However I don't much like the idea that VFIO will
> have a special and unique programming model to do that same things
> other
> From: Jason Gunthorpe
> Sent: Wednesday, April 28, 2021 1:12 AM
>
[...]
> > As Alex says, if this line fails because of the group restrictions,
> > that's not great because it's not very obvious what's gone wrong.
>
> Okay, that is fair, but let's solve that problem directly. For
> instance
> From: Jason Gunthorpe
> Sent: Monday, April 26, 2021 8:38 PM
>
[...]
> > Want to hear your opinion for one open here. There is no doubt that
> > an ioasid represents a HW page table when the table is constructed by
> > userspace and then linked to the IOMMU through the bind/unbind
> > API. But
> From: Jason Gunthorpe
> Sent: Friday, April 23, 2021 7:50 PM
>
> On Fri, Apr 23, 2021 at 09:06:44AM +, Tian, Kevin wrote:
>
> > Or could we still have just one /dev/ioasid but allow userspace to create
> > multiple gpa_ioasid_id's each associated
> From: Jason Gunthorpe
> Sent: Friday, April 23, 2021 7:40 AM
>
> On Thu, Apr 22, 2021 at 04:38:08PM -0600, Alex Williamson wrote:
>
> > Because it's fundamental to the isolation of the device? What you're
> > proposing doesn't get around the group issue, it just makes it implicit
> > rather
> From: Jason Gunthorpe
> Sent: Thursday, April 22, 2021 8:10 PM
>
> On Thu, Apr 22, 2021 at 08:34:32AM +, Tian, Kevin wrote:
>
> > Another tricky thing is that a container may be linked to multiple iommu
> > domains in VFIO, as devices in the container
> From: Jason Gunthorpe
> Sent: Thursday, April 22, 2021 7:03 AM
>
> > The pseudo code above really suggests you do want to remove
> > /dev/vfio/vfio, but this is only one of the IOMMU backends for vfio, so
> > I can't quite figure out if we're talking past each other.
>
> I'm not quite sure
> From: Jason Gunthorpe
> Sent: Wednesday, April 7, 2021 8:21 PM
>
> On Wed, Apr 07, 2021 at 02:08:33AM +, Tian, Kevin wrote:
>
> > > Because if you don't then we enter insane world where a PASID is being
> > > created under /dev/ioasid but its tra
> From: Jason Gunthorpe
> Sent: Tuesday, April 6, 2021 8:43 PM
>
> On Tue, Apr 06, 2021 at 09:35:17AM +0800, Jason Wang wrote:
>
> > > VFIO and VDPA has no buisness having map/unmap interfaces once we
> have
> > > /dev/ioasid. That all belongs in the iosaid side.
> > >
> > > I know they have
> From: Jason Gunthorpe
> Sent: Tuesday, April 6, 2021 8:21 PM
>
> On Tue, Apr 06, 2021 at 01:02:05AM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Tuesday, April 6, 2021 7:40 AM
> > >
> > > On Fri, Apr 02, 2021 at 07:58:02AM
> From: Jason Gunthorpe
> Sent: Tuesday, April 6, 2021 8:35 PM
>
> On Tue, Apr 06, 2021 at 01:27:15AM +, Tian, Kevin wrote:
> >
> > and here is one example why using existing VFIO/VDPA interface makes
> > sense. say dev1 (w/ sva) and dev2 (w/o sva) are placed
> From: Tian, Kevin
> Sent: Tuesday, April 6, 2021 9:02 AM
>
> > From: Jason Gunthorpe
> > Sent: Tuesday, April 6, 2021 7:40 AM
> >
> > On Fri, Apr 02, 2021 at 07:58:02AM +, Tian, Kevin wrote:
> > > > From: Jason Gunthorpe
> > > > Sen
> From: Jason Gunthorpe
> Sent: Tuesday, April 6, 2021 7:43 AM
>
> On Fri, Apr 02, 2021 at 08:22:28AM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Tuesday, March 30, 2021 9:29 PM
> > >
> > > >
> > > > Fir
> From: Jason Gunthorpe
> Sent: Tuesday, April 6, 2021 7:40 AM
>
> On Fri, Apr 02, 2021 at 07:58:02AM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Thursday, April 1, 2021 9:47 PM
> > >
> > > On Thu, Apr 01, 2021 at 01:43:36
> From: Jason Gunthorpe
> Sent: Tuesday, April 6, 2021 7:35 AM
>
> On Fri, Apr 02, 2021 at 07:30:23AM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Friday, April 2, 2021 12:04 AM
> > >
> > > On Thu, Apr 01, 2021 at 02:08:17P
> From: Tian, Kevin
> Sent: Friday, April 2, 2021 3:58 PM
>
> > From: Jason Gunthorpe
> > Sent: Thursday, April 1, 2021 9:47 PM
> >
> > On Thu, Apr 01, 2021 at 01:43:36PM +, Liu, Yi L wrote:
> > > > From: Jason Gunthorpe
> > > > Sen
> From: Jason Gunthorpe
> Sent: Tuesday, March 30, 2021 9:29 PM
>
> >
> > First, userspace may use ioasid in a non-SVA scenario where ioasid is
> > bound to specific security context (e.g. a control vq in vDPA) instead of
> > tying to mm. In this case there is no pgtable binding initiated from
> From: Jason Gunthorpe
> Sent: Thursday, April 1, 2021 9:47 PM
>
> On Thu, Apr 01, 2021 at 01:43:36PM +, Liu, Yi L wrote:
> > > From: Jason Gunthorpe
> > > Sent: Thursday, April 1, 2021 9:16 PM
> > >
> > > On Thu, Apr 01, 2021 at 01:10:48PM +, Liu, Yi L wrote:
> > > > > From: Jason
> From: Jason Gunthorpe
> Sent: Friday, April 2, 2021 12:04 AM
>
> On Thu, Apr 01, 2021 at 02:08:17PM +, Liu, Yi L wrote:
>
> > DMA page faults are delivered to root-complex via page request message
> and
> > it is per-device according to PCIe spec. Page request handling flow is:
> >
> > 1)
> From: Tian, Kevin
> Sent: Tuesday, March 30, 2021 10:24 AM
>
> > From: Jason Gunthorpe
> > Sent: Tuesday, March 30, 2021 12:32 AM
> > > In terms of usage for guest SVA, an ioasid_set is mostly tied to a host
> > > mm,
> > > the use
> From: Jason Gunthorpe
> Sent: Tuesday, March 30, 2021 12:32 AM
> > In terms of usage for guest SVA, an ioasid_set is mostly tied to a host mm,
> > the use case is as the following:
>
> From that doc:
>
> It is imperative to enforce
> VM-IOASID ownership such that a malicious guest cannot
> From: Jason Gunthorpe
> Sent: Tuesday, March 30, 2021 12:32 AM
>
> On Wed, Mar 24, 2021 at 12:05:28PM -0700, Jacob Pan wrote:
>
> > > IMHO a use created PASID is either bound to a mm (current) at creation
> > > time, or it will never be bound to a mm and its page table is under
> > > user
> From: Auger Eric
> Sent: Monday, March 15, 2021 3:52 PM
> To: Christoph Hellwig
> Cc: k...@vger.kernel.org; Will Deacon ; linuxppc-
> d...@lists.ozlabs.org; dri-de...@lists.freedesktop.org; Li Yang
> ; iommu@lists.linux-foundation.org;
>
> Hi Christoph,
>
> On 3/14/21 4:58 PM, Christoph
> From: Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
>
>
> > -Original Message-
> > From: Tian, Kevin [mailto:kevin.t...@intel.com]
> > Sent: Thursday, March 18, 2021 4:27 PM
> > To: Longpeng (Mike, Cloud Infrastructure Service Produc
> From: Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
>
>
>
> > -Original Message-----
> > From: Tian, Kevin [mailto:kevin.t...@intel.com]
> > Sent: Thursday, March 18, 2021 4:27 PM
> > To: Longpeng (Mike, Cloud Infrastructure Service Pro
> From: iommu On Behalf Of
> Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
>
> > 2. Consider ensuring that the problem is not somehow related to queued
> > invalidations. Try to use __iommu_flush_iotlb() instead of qi_flush_iotlb().
> >
>
> I tried to force to use
> From: Jacob Pan
> Sent: Thursday, March 4, 2021 2:29 AM
>
> Hi Vivek,
>
> On Fri, 15 Jan 2021 17:43:39 +0530, Vivek Gautam
> wrote:
>
> > From: Jean-Philippe Brucker
> >
> > Add support for tlb invalidation ops that can send invalidation
> > requests to back-end virtio-iommu when stage-1
> From: Jacob Pan
> Sent: Saturday, February 20, 2021 1:09 AM
>
> Hi Kevin,
>
> On Fri, 19 Feb 2021 06:19:04 +, "Tian, Kevin"
> wrote:
>
> > > From: Jacob Pan
> > > Sent: Friday, February 19, 2021 5:31 AM
> > >
> > &g
> From: Jacob Pan
> Sent: Friday, February 19, 2021 5:31 AM
>
> Write protect bit, when set, inhibits supervisor writes to the read-only
> pages. In guest supervisor shared virtual addressing (SVA), write-protect
> should be honored upon guest bind supervisor PASID request.
>
> This patch
742.18840-1-
> zhukeqi...@huawei.com/
Thanks for the pointer. We will take a look.
>
> On 2020/5/27 17:14, Jean-Philippe Brucker wrote:
> > On Wed, May 27, 2020 at 08:40:47AM +, Tian, Kevin wrote:
> >>> From: Xiang Zheng
> >>> Sent: Wednesday, May 27, 2020 2:
> From: Lu Baolu
> Sent: Wednesday, February 3, 2021 5:33 PM
>
> From: Yian Chen
>
> Starting from Intel VT-d v3.2, Intel platform BIOS can provide a new SATC
> table structure. SATC table lists a set of SoC integrated devices that
> require ATC to work (VT-d specification v3.2, section 8.8).
> From: Jason Gunthorpe
> Sent: Tuesday, February 2, 2021 7:44 AM
>
> On Fri, Jan 29, 2021 at 10:09:03AM +, Tian, Kevin wrote:
> > > SVA is not doom to work with IO page fault only. If we have SVA+pin,
> > > we would get both sharing address and stable I/O
> From: Song Bao Hua (Barry Song)
> Sent: Tuesday, January 26, 2021 9:27 AM
>
> > -Original Message-
> > From: Jason Gunthorpe [mailto:j...@ziepe.ca]
> > Sent: Tuesday, January 26, 2021 2:13 PM
> > To: Song Bao Hua (Barry Song)
> > Cc: Wangzhou (B) ; Greg Kroah-Hartman
> > ; Arnd
> From: Lu Baolu
> Sent: Monday, January 25, 2021 2:29 PM
>
> Hi Kevin,
>
> On 2021/1/22 14:38, Tian, Kevin wrote:
> >> From: Lu Baolu
> >> Sent: Thursday, January 21, 2021 9:45 AM
> >>
> >> So that the uses could get chances to
> From: Lu Baolu
> Sent: Thursday, January 21, 2021 9:45 AM
>
> So that the uses could get chances to know what happened.
>
> Suggested-by: Ashok Raj
> Signed-off-by: Lu Baolu
> ---
> drivers/iommu/intel/svm.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git
> From: Lu Baolu
> Sent: Saturday, January 16, 2021 11:54 AM
>
> Hi Jean,
>
> On 2021/1/15 0:41, Jean-Philippe Brucker wrote:
> > I guess detailing what's needed for nested IOPF can help the discussion,
> > although I haven't seen any concrete plan about implementing it, and it
> > still seems
> From: Lu Baolu
> Sent: Thursday, January 14, 2021 9:30 AM
>
> The pci_subdevice_msi_create_irq_domain() should fail if the underlying
> platform is not able to support IMS (Interrupt Message Storage). Otherwise,
> the isolation of interrupt is not guaranteed.
>
> For x86, IMS is only supported
> From: Lu Baolu
> Sent: Wednesday, January 13, 2021 10:50 AM
>
> Hi Jean,
>
> On 1/12/21 5:16 PM, Jean-Philippe Brucker wrote:
> > Hi Baolu,
> >
> > On Tue, Jan 12, 2021 at 12:31:23PM +0800, Lu Baolu wrote:
> >> Hi Jean,
> >>
> >> On 1/8/21 10:52 PM, Jean-Philippe Brucker wrote:
> >>> Some
> From: Lu Baolu
> Sent: Friday, October 30, 2020 12:58 PM
>
> With the IOMMU driver registering iommu_ops for the mdev_bus, the
> IOMMU
> operations on an mdev could be done in the same way as any normal device
> (for example, PCI/PCIe). There's no need to distinguish an mdev from
> others for
> From: Lu Baolu
> Sent: Friday, October 30, 2020 12:58 PM
>
> The iommu_ops will only take effect when INTEL_IOMMU_SCALABLE_IOV
> kernel
> option is selected. It applies to any device passthrough framework which
> implements an underlying bus for the subdevices.
>
> - Subdevice probe:
> When
401 - 500 of 775 matches
Mail list logo
