> 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 assoc
> 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 host
> 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: 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: 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 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: 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 type
> 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 tran
> 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: 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 == -EOP
> 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: 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: 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: 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 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 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 t
/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 propos
> 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 what
> 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 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: 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 translation.
> 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 par
> 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: 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: 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 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: 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: 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: 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. I
> 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 = gva_pgta
> 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: 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 gues
> 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
> > >
> > > On Wed, 2 Jun 20
> 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: 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: 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" devi
> 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: 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: 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 I
> 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 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 (e
> 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: 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 sharin
> 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 lab
> 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 at
> 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: 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
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
prov
> 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, Pa
> 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 inte
> 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 KVM_DEV_IO
> 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: 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: 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
Hi, Alex,
> From: Alex Williamson
> Sent: Thursday, June 10, 2021 11:39 PM
>
> On Wed, 9 Jun 2021 15:49:40 -0300
> Jason Gunthorpe wrote:
>
> > On Wed, Jun 09, 2021 at 10:27:22AM -0600, Alex Williamson wrote:
> >
> > > > > It is a kernel decision, because a fundamental task of the kernel is
>
> From: Alex Williamson
> Sent: Saturday, June 12, 2021 5:39 AM
>
> On Fri, 11 Jun 2021 00:58:35 +0000
> "Tian, Kevin" wrote:
>
> > Hi, Alex,
> >
> > > From: Alex Williamson
> > > Sent: Thursday, June 10, 2021 11:39 PM
> > >
&
> From: Alex Williamson
> Sent: Monday, June 14, 2021 11:23 AM
>
[...]
> > In the meantime, I'm thinking about another way whether group
> > security can be enforced in the iommu layer to relax the uAPI design.
> > If a device can be always blocked from accessing memory in the
> > IOMMU before it
> From: Jason Gunthorpe
> Sent: Monday, June 14, 2021 9:38 PM
>
> On Mon, Jun 14, 2021 at 03:09:31AM +, Tian, Kevin wrote:
>
> > If a device can be always blocked from accessing memory in the IOMMU
> > before it's bound to a driver or more specifically bef
> From: Alex Williamson
> Sent: Tuesday, June 15, 2021 12:28 AM
>
[...]
> > IOASID. Today the group fd requires an IOASID before it hands out a
> > device_fd. With iommu_fd the device_fd will not allow IOCTLs until it
> > has a blocked DMA IOASID and is successefully joined to an iommu_fd.
>
> W
Hi, Jason,
> From: Jason Gunthorpe
> Sent: Thursday, June 3, 2021 9:05 PM
>
> On Thu, Jun 03, 2021 at 06:39:30AM +, Tian, Kevin wrote:
> > > > Two helper functions are provided to support VFIO_ATTACH_IOASID:
> > > >
> > > > struct atta
> From: Jason Gunthorpe
> Sent: Tuesday, June 15, 2021 11:07 PM
>
> On Tue, Jun 15, 2021 at 08:59:25AM +, Tian, Kevin wrote:
> > Hi, Jason,
> >
> > > From: Jason Gunthorpe
> > > Sent: Thursday, June 3, 2021 9:05 PM
> > >
> > >
> From: Jason Gunthorpe
> Sent: Wednesday, June 16, 2021 7:02 AM
>
> On Tue, Jun 15, 2021 at 10:59:06PM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Tuesday, June 15, 2021 11:07 PM
> > >
> > > On Tue, Jun 15, 2021 at 08:59:
> From: Jason Gunthorpe
> Sent: Wednesday, June 16, 2021 7:41 AM
>
> On Tue, Jun 15, 2021 at 11:09:37PM +, Tian, Kevin wrote:
>
> > which information can you elaborate? This is the area which I'm not
> > familiar with thus would appreciate if you can help e
> From: Jason Gunthorpe
> Sent: Wednesday, June 16, 2021 7:59 AM
>
> On Tue, Jun 15, 2021 at 11:56:28PM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Wednesday, June 16, 2021 7:41 AM
> > >
> > > On Tue, Jun 15, 2021 at 11:09:37
> From: Alex Williamson
> Sent: Wednesday, June 16, 2021 12:12 AM
>
> On Tue, 15 Jun 2021 02:31:39 +0000
> "Tian, Kevin" wrote:
>
> > > From: Alex Williamson
> > > Sent: Tuesday, June 15, 2021 12:28 AM
> > >
> > [...]
> > >
> From: Alex Williamson
> Sent: Wednesday, June 16, 2021 12:56 AM
>
> On Tue, 15 Jun 2021 01:21:35 +0000
> "Tian, Kevin" wrote:
>
> > > From: Jason Gunthorpe
> > > Sent: Monday, June 14, 2021 9:38 PM
> > >
> > > On Mon, Jun 14,
> From: Alex Williamson
> Sent: Thursday, June 17, 2021 3:40 AM
>
> On Wed, 16 Jun 2021 06:43:23 +0000
> "Tian, Kevin" wrote:
>
> > > From: Alex Williamson
> > > Sent: Wednesday, June 16, 2021 12:12 AM
> > >
> > &g
> From: Jason Gunthorpe
> Sent: Friday, June 18, 2021 8:20 AM
>
> On Thu, Jun 17, 2021 at 03:14:52PM -0600, Alex Williamson wrote:
>
> > I've referred to this as a limitation of type1, that we can't put
> > devices within the same group into different address spaces, such as
> > behind separate
> From: Jean-Philippe Brucker
> Sent: Saturday, June 19, 2021 1:04 AM
>
> On Thu, Jun 17, 2021 at 01:00:14PM +1000, David Gibson wrote:
> > On Thu, Jun 10, 2021 at 06:37:31PM +0200, Jean-Philippe Brucker wrote:
> > > On Tue, Jun 08, 2021 at 04:31:50PM +1000, David Gibson wrote:
> > > > For the qem
> From: David Gibson
> Sent: Thursday, June 17, 2021 11:48 AM
>
> On Tue, Jun 08, 2021 at 10:17:56AM -0300, Jason Gunthorpe wrote:
> > On Tue, Jun 08, 2021 at 12:37:04PM +1000, David Gibson wrote:
> >
> > > > The PPC/SPAPR support allows KVM to associate a vfio group to an
> IOMMU
> > > > page ta
> From: David Gibson
> Sent: Thursday, June 17, 2021 12:08 PM
>
> On Thu, Jun 03, 2021 at 08:12:27AM +, Tian, Kevin wrote:
> > > From: David Gibson
> > > Sent: Wednesday, June 2, 2021 2:15 PM
> > >
> > [...]
> >
> > > >
&g
> From: Jason Gunthorpe
> Sent: Saturday, June 19, 2021 2:31 AM
>
> On Fri, Jun 18, 2021 at 07:03:31PM +0200, Jean-Philippe Brucker wrote:
>
> > configuration. The Arm SMMUs have a lot of small features that
> > implementations can mix and match and that a user shouldn't have to care
> > about,
> From: David Gibson
> Sent: Thursday, June 24, 2021 12:26 PM
>
> On Fri, Jun 18, 2021 at 04:57:40PM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Friday, June 18, 2021 8:20 AM
> > >
> > > On Thu, Jun 17, 2021 at 03:14:52PM
Hi, Alex/Joerg/Jason,
Want to draw your attention on an updated proposal below. Let's see
whether there is a converged direction to move forward. 😊
> From: Jason Gunthorpe
> Sent: Saturday, June 19, 2021 2:23 AM
>
> On Fri, Jun 18, 2021 at 04:57:40PM +, Tian, Kevin
> From: Jason Gunthorpe
> Sent: Friday, June 25, 2021 10:36 PM
>
> On Fri, Jun 25, 2021 at 10:27:18AM +, Tian, Kevin wrote:
>
> > - When receiving the binding call for the 1st device in a group, iommu_fd
> > calls iommu_group_set_block_dma(gro
Hi, Jason,
> From: Jason Gunthorpe
> Sent: Friday, June 25, 2021 10:36 PM
>
> The only thing that needs to be done to get the 1:1 step is to broadly
> define how the other two cases will work so we don't get into trouble
> and set some way to exclude the problematic cases from even getting to
>
> From: Jason Gunthorpe
> Sent: Friday, June 25, 2021 10:36 PM
>
> On Fri, Jun 25, 2021 at 10:27:18AM +, Tian, Kevin wrote:
>
> > - When receiving the binding call for the 1st device in a group, iommu_fd
> > calls iommu_group_set_block_dma(gro
> From: Jason Gunthorpe
> Sent: Tuesday, June 29, 2021 7:13 AM
>
> On Mon, Jun 28, 2021 at 05:09:02PM -0600, Alex Williamson wrote:
> > On Mon, 28 Jun 2021 19:48:18 -0300
> > Jason Gunthorpe wrote:
> >
> > > On Mon, Jun 28, 2021 at 04:31:45PM -0600, Alex Williamson wrote:
> > >
> > > > I'd expect
> From: Alex Williamson
> Sent: Tuesday, June 29, 2021 7:09 AM
>
> > > Ideally vfio would also at least be able to register a type1 IOMMU
> > > backend through the existing uapi, backed by this iommu code, ie. we'd
> > > create a new "iommufd" (but without the user visible fd),
> >
> > It would b
> From: Alex Williamson
> Sent: Tuesday, June 29, 2021 6:32 AM
>
> On Mon, 28 Jun 2021 01:09:18 +0000
> "Tian, Kevin" wrote:
>
> > > From: Jason Gunthorpe
> > > Sent: Friday, June 25, 2021 10:36 PM
> > >
> > > On Fri, Jun 25, 202
> From: Joerg Roedel
> Sent: Monday, May 17, 2021 11:35 PM
>
> On Mon, May 17, 2021 at 10:35:00AM -0300, Jason Gunthorpe wrote:
> > Well, I'm sorry, but there is a huge other thread talking about the
> > IOASID design in great detail and why this is all needed. Jumping into
> > this thread withou
/dev/iommu 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 proposa
> From: Alex Williamson
> Sent: Saturday, July 10, 2021 5:51 AM
>
> Hi Kevin,
>
> A couple first pass comments...
>
> On Fri, 9 Jul 2021 07:48:44 +
> "Tian, Kevin" wrote:
> > 2.2. /dev/vfio device uAPI
> > ++
>
> From: Alex Williamson
> Sent: Tuesday, July 13, 2021 2:42 AM
>
> On Mon, 12 Jul 2021 01:22:11 +0000
> "Tian, Kevin" wrote:
> > > From: Alex Williamson
> > > Sent: Saturday, July 10, 2021 5:51 AM
> > > On Fri, 9 Jul 2021 07:48:44 +
> From: Alex Williamson
> Sent: Tuesday, July 13, 2021 2:42 AM
>
> On Mon, 12 Jul 2021 01:22:11 +0000
> "Tian, Kevin" wrote:
> > > From: Alex Williamson
> > > Sent: Saturday, July 10, 2021 5:51 AM
> > > On Fri, 9 Jul 2021 07:48:44 +
> From: Jason Gunthorpe
> Sent: Wednesday, July 14, 2021 12:33 AM
>
> On Tue, Jul 13, 2021 at 10:26:07AM -0600, Alex Williamson wrote:
> > Quoting this proposal again:
> >
> > > 1) A successful binding call for the first device in the group creates
> > > the security context for the entire g
> From: Jason Gunthorpe
> Sent: Wednesday, July 14, 2021 7:03 AM
>
> On Tue, Jul 13, 2021 at 10:48:38PM +, Tian, Kevin wrote:
>
> > We can still bind to the parent with cookie, but with
> > iommu_register_ sw_device() IOMMU fd knows that this binding doesn&
> From: Jason Gunthorpe
> Sent: Wednesday, July 14, 2021 7:23 AM
>
> On Tue, Jul 13, 2021 at 11:20:12PM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Wednesday, July 14, 2021 7:03 AM
> > >
> > > On Tue, Jul 13, 2021 at 10:48
> From: Shenming Lu
> Sent: Thursday, July 15, 2021 11:21 AM
>
> On 2021/7/9 15:48, Tian, Kevin wrote:
> > 4.6. I/O page fault
> > +++
> >
> > uAPI is TBD. Here is just about the high-level flow from host IOMMU driver
> > to guest IOM
> From: Shenming Lu
> Sent: Thursday, July 15, 2021 2:29 PM
>
> On 2021/7/15 11:55, Tian, Kevin wrote:
> >> From: Shenming Lu
> >> Sent: Thursday, July 15, 2021 11:21 AM
> >>
> >> On 2021/7/9 15:48, Tian, Kevin wrote:
> >>> 4.6. I/O
> From: Jason Gunthorpe
> Sent: Friday, July 16, 2021 2:13 AM
>
> On Thu, Jul 15, 2021 at 11:05:45AM -0700, Raj, Ashok wrote:
> > On Thu, Jul 15, 2021 at 02:53:36PM -0300, Jason Gunthorpe wrote:
> > > On Thu, Jul 15, 2021 at 10:48:36AM -0700, Raj, Ashok wrote:
> > >
> > > > > > Do we have any iso
> From: Jason Gunthorpe
> Sent: Saturday, July 17, 2021 2:30 AM
>
> On Fri, Jul 16, 2021 at 01:20:15AM +, Tian, Kevin wrote:
>
> > One thought is to have vfio device driver deal with it. In this proposal
> > it is the vfio device driver to define the PASI
> From: Shenming Lu
> Sent: Friday, July 16, 2021 8:20 PM
>
> On 2021/7/16 9:20, Tian, Kevin wrote:
> > To summarize, for vIOMMU we can work with the spec owner to
> > define a proper interface to feedback such restriction into the guest
> > if necessary. For th
A gentle ping...
> From: Tian, Kevin
> Sent: Wednesday, June 30, 2021 5:08 PM
>
> > From: Joerg Roedel
> > Sent: Monday, May 17, 2021 11:35 PM
> >
> > On Mon, May 17, 2021 at 10:35:00AM -0300, Jason Gunthorpe wrote:
> > > Well, I'm sorry, but
> From: Christoph Hellwig
> Sent: Thursday, July 22, 2021 9:35 PM
>
> On Wed, Jun 30, 2021 at 09:08:19AM +, Tian, Kevin wrote:
> > The iommu layer should maintain above attaching status per device and
> per
> > iommu domain. There is no mdev/subdev concept in the
> From: Christoph Hellwig
> Sent: Friday, July 23, 2021 1:41 PM
>
> On Fri, Jul 23, 2021 at 05:36:17AM +, Tian, Kevin wrote:
> > > > And a new set of IOMMU-API:
> > > >
> > > > - iommu_{un}bind_pgtable(domain, dev, addr);
> > &g
Hi, David,
> From: David Gibson
> Sent: Monday, July 26, 2021 12:51 PM
>
> On Fri, Jul 09, 2021 at 07:48:44AM +, Tian, Kevin wrote:
> > /dev/iommu provides an unified interface for managing I/O page tables for
> > devices assigned to userspace. Device passthrough
> From: Jean-Philippe Brucker
> Sent: Monday, July 26, 2021 4:15 PM
>
> Hi Kevin,
>
> On Fri, Jul 09, 2021 at 07:48:44AM +, Tian, Kevin wrote:
> > /dev/iommu provides an unified interface for managing I/O page tables for
> > devices assigned to userspace. Devic
> From: Jason Gunthorpe
> Sent: Friday, July 30, 2021 10:51 PM
>
> On Mon, Jul 26, 2021 at 02:50:48PM +1000, David Gibson wrote:
>
> > That said, I'm still finding the various ways a device can attach to
> > an ioasid pretty confusing. Here are some thoughts on some extra
> > concepts that migh
> From: David Gibson
> Sent: Tuesday, August 3, 2021 9:51 AM
>
> On Wed, Jul 28, 2021 at 04:04:24AM +, Tian, Kevin wrote:
> > Hi, David,
> >
> > > From: David Gibson
> > > Sent: Monday, July 26, 2021 12:51 PM
> > >
> > >
501 - 600 of 784 matches
Mail list logo
