On Fri, Aug 06, 2021 at 09:32:11AM -0300, Jason Gunthorpe wrote:
> On Fri, Aug 06, 2021 at 02:45:26PM +1000, David Gibson wrote:
>
> > Well, that's kind of what I'm doing. PCI currently has the notion of
> > "default" address space for a RID, but there's no guarantee that other
> > buses (or
> From: Eric Auger
> Sent: Tuesday, August 10, 2021 3:17 PM
>
> Hi Kevin,
>
> On 8/5/21 2:36 AM, Tian, Kevin wrote:
> >> From: Eric Auger
> >> Sent: Wednesday, August 4, 2021 11:59 PM
> >>
> > [...]
> >>> 1.2. Attach Device to I/O address space
> >>> +++
>
Hi Kevin,
On 8/5/21 2:36 AM, Tian, Kevin wrote:
>> From: Eric Auger
>> Sent: Wednesday, August 4, 2021 11:59 PM
>>
> [...]
>>> 1.2. Attach Device to I/O address space
>>> +++
>>>
>>> Device attach/bind is initiated through passthrough framework uAPI.
>>>
>>>
> From: David Gibson
> Sent: Tuesday, August 10, 2021 12:48 PM
>
> On Mon, Aug 09, 2021 at 08:34:06AM +, Tian, Kevin wrote:
> > > From: David Gibson
> > > Sent: Friday, August 6, 2021 12:45 PM
> > > > > > In concept I feel the purpose of DMA endpoint is equivalent to the
> > > routing
> > >
On Mon, Aug 09, 2021 at 08:34:06AM +, Tian, Kevin wrote:
> > From: David Gibson
> > Sent: Friday, August 6, 2021 12:45 PM
> > > > > In concept I feel the purpose of DMA endpoint is equivalent to the
> > routing
> > > > > info in this proposal.
> > > >
> > > > Maybe? I'm afraid I never quite
> From: David Gibson
> Sent: Friday, August 6, 2021 12:45 PM
> > > > In concept I feel the purpose of DMA endpoint is equivalent to the
> routing
> > > > info in this proposal.
> > >
> > > Maybe? I'm afraid I never quite managed to understand the role of the
> > > routing info in your proposal.
On Fri, Aug 06, 2021 at 02:45:26PM +1000, David Gibson wrote:
> Well, that's kind of what I'm doing. PCI currently has the notion of
> "default" address space for a RID, but there's no guarantee that other
> buses (or even future PCI extensions) will. The idea is that
> "endpoint" means exactly
On Tue, Aug 03, 2021 at 03:19:26AM +, Tian, Kevin wrote:
> > 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
> > >
On Wed, Aug 04, 2021 at 11:04:47AM -0300, Jason Gunthorpe wrote:
> On Mon, Aug 02, 2021 at 02:49:44AM +, Tian, Kevin wrote:
>
> > Can you elaborate? IMO the user only cares about the label (device cookie
> > plus optional vPASID) which is generated by itself when doing the attaching
> >
On Wed, Aug 04, 2021 at 11:07:42AM -0300, Jason Gunthorpe wrote:
> On Tue, Aug 03, 2021 at 11:58:54AM +1000, David Gibson wrote:
> > > I'd rather deduce the endpoint from a collection of devices than the
> > > other way around...
> >
> > Which I think is confusing, and in any case doesn't cover
> From: Jason Gunthorpe
> Sent: Thursday, August 5, 2021 7:27 PM
>
> On Wed, Aug 04, 2021 at 10:59:21PM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Wednesday, August 4, 2021 10:05 PM
> > >
> > > On Mon, Aug 02, 2021 at 02:49:44AM +, Tian, Kevin wrote:
> > >
> > > > Can
On Wed, Aug 04, 2021 at 10:59:21PM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Wednesday, August 4, 2021 10:05 PM
> >
> > On Mon, Aug 02, 2021 at 02:49:44AM +, Tian, Kevin wrote:
> >
> > > Can you elaborate? IMO the user only cares about the label (device cookie
> > > plus
> From: Eric Auger
> Sent: Wednesday, August 4, 2021 11:59 PM
>
[...]
> > 1.2. Attach Device to I/O address space
> > +++
> >
> > Device attach/bind is initiated through passthrough framework uAPI.
> >
> > Device attaching is allowed only after a device is
> From: Jason Gunthorpe
> Sent: Wednesday, August 4, 2021 10:05 PM
>
> On Mon, Aug 02, 2021 at 02:49:44AM +, Tian, Kevin wrote:
>
> > Can you elaborate? IMO the user only cares about the label (device cookie
> > plus optional vPASID) which is generated by itself when doing the attaching
> >
Hi Kevin,
Few comments/questions below.
On 7/9/21 9:48 AM, Tian, Kevin wrote:
> /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
On Tue, Aug 03, 2021 at 11:58:54AM +1000, David Gibson wrote:
> > I'd rather deduce the endpoint from a collection of devices than the
> > other way around...
>
> Which I think is confusing, and in any case doesn't cover the case of
> one "device" with multiple endpoints.
Well they are both
On Mon, Aug 02, 2021 at 02:49:44AM +, Tian, Kevin wrote:
> Can you elaborate? IMO the user only cares about the label (device cookie
> plus optional vPASID) which is generated by itself when doing the attaching
> call, and expects this virtual label being used in various spots
>
> 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
> > >
> > > On Fri, Jul 09, 2021 at 07:48:44AM +, Tian, Kevin wrote:
> > > >
On Fri, Jul 30, 2021 at 11:51:23AM -0300, Jason Gunthorpe wrote:
> 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 might
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
> >
> > 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
> > >
> 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
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 might make it easier to handle [note, I haven't thought
> this all the way
> 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. Device passthrough frameworks
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 frameworks (VFIO,
> vDPA,
>
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. Device passthrough frameworks (VFIO, vDPA,
> etc.) are expected to use this interface instead of creating their own
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 frameworks (VFIO, vDPA,
> etc.) are expected to use this interface instead of creating their own logic
>
On Wed, Jul 21, 2021 at 02:13:23AM +, Tian, Kevin wrote:
> > 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
> 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 the kernel part, it's clear that
> 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 PASID virtualization policy and
> >
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 PASID virtualization policy and
> report it to userspace via VFIO_DEVICE_GET_INFO. The driver understands
> the
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 the kernel part, it's clear that IOMMU fd should
> disallow two devices attached to a single [RID] or
> 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
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 isolation requirements here? its the same process. So
> > > > > if the
> > >
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 isolation requirements here? its the same process. So if
> > > > the
> > > > page-request it sent to guest and even if you report it for mdev1,
On Thu, Jul 15, 2021 at 10:48:36AM -0700, Raj, Ashok wrote:
> > > Do we have any isolation requirements here? its the same process. So if
> > > the
> > > page-request it sent to guest and even if you report it for mdev1, after
> > > the PRQ is resolved by guest, the request from mdev2 from the
On Thu, Jul 15, 2021 at 02:18:26PM -0300, Jason Gunthorpe wrote:
> On Thu, Jul 15, 2021 at 09:21:41AM -0700, Raj, Ashok wrote:
> > On Thu, Jul 15, 2021 at 12:23:25PM -0300, Jason Gunthorpe wrote:
> > > On Thu, Jul 15, 2021 at 06:57:57AM -0700, Raj, Ashok wrote:
> > > > On Thu, Jul 15, 2021 at
On Thu, Jul 15, 2021 at 09:21:41AM -0700, Raj, Ashok wrote:
> On Thu, Jul 15, 2021 at 12:23:25PM -0300, Jason Gunthorpe wrote:
> > On Thu, Jul 15, 2021 at 06:57:57AM -0700, Raj, Ashok wrote:
> > > On Thu, Jul 15, 2021 at 09:48:13AM -0300, Jason Gunthorpe wrote:
> > > > On Thu, Jul 15, 2021 at
On Thu, Jul 15, 2021 at 12:23:25PM -0300, Jason Gunthorpe wrote:
> On Thu, Jul 15, 2021 at 06:57:57AM -0700, Raj, Ashok wrote:
> > On Thu, Jul 15, 2021 at 09:48:13AM -0300, Jason Gunthorpe wrote:
> > > On Thu, Jul 15, 2021 at 06:49:54AM +, Tian, Kevin wrote:
> > >
> > > > No. You are right on
On Thu, Jul 15, 2021 at 06:57:57AM -0700, Raj, Ashok wrote:
> On Thu, Jul 15, 2021 at 09:48:13AM -0300, Jason Gunthorpe wrote:
> > On Thu, Jul 15, 2021 at 06:49:54AM +, Tian, Kevin wrote:
> >
> > > No. You are right on this case. I don't think there is a way to
> > > differentiate one mdev
On Thu, Jul 15, 2021 at 09:48:13AM -0300, Jason Gunthorpe wrote:
> On Thu, Jul 15, 2021 at 06:49:54AM +, Tian, Kevin wrote:
>
> > No. You are right on this case. I don't think there is a way to
> > differentiate one mdev from the other if they come from the
> > same parent and attached by
On Thu, Jul 15, 2021 at 06:49:54AM +, Tian, Kevin wrote:
> No. You are right on this case. I don't think there is a way to
> differentiate one mdev from the other if they come from the
> same parent and attached by the same guest process. In this
> case the fault could be reported on either
On 2021/7/15 14:49, Tian, Kevin wrote:
>> 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 page fault
>
> 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 page fault
> >>> +++
> >>>
> >>> uAPI is TBD.
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 page fault
>>> +++
>>>
>>> uAPI is TBD. Here is just about the high-level flow from host IOMMU driver
>>> to guest IOMMU
> 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 IOMMU driver and backwards. This flow assumes
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 IOMMU driver and backwards. This flow assumes that I/O page faults
> are reported via IOMMU interrupts. Some devices report
> 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:38PM +, Tian, Kevin wrote:
> > >
> > > > We
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:38PM +, Tian, Kevin wrote:
> >
> > > We can still bind to the parent with cookie, but with
> > > iommu_register_
> 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't
> > need to establish any
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't
> need to establish any security context via IOMMU API.
AFAIK there is no reason to involve the parent PCI
> 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
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 group, by:
> >
> > * Verifying group viability in a similar way as VFIO
On Tue, 13 Jul 2021 09:55:03 -0300
Jason Gunthorpe wrote:
> On Mon, Jul 12, 2021 at 11:56:24PM +, Tian, Kevin wrote:
>
> > Maybe I misunderstood your question. Are you specifically worried
> > about establishing the security context for a mdev vs. for its
> > parent?
>
> The way to think
On Mon, Jul 12, 2021 at 11:56:24PM +, Tian, Kevin wrote:
> Maybe I misunderstood your question. Are you specifically worried
> about establishing the security context for a mdev vs. for its
> parent?
The way to think about the cookie, and the device bind/attach in
general, is as taking
> From: Alex Williamson
> Sent: Tuesday, July 13, 2021 2:42 AM
>
> On Mon, 12 Jul 2021 01:22:11 +
> "Tian, Kevin" wrote:
> > > From: Alex Williamson
> > > Sent: Saturday, July 10, 2021 5:51 AM
> > > On Fri, 9 Jul 2021 07:48:44 +
> > > "Tian, Kevin" wrote:
>
> > > > For mdev the
> From: Alex Williamson
> Sent: Tuesday, July 13, 2021 2:42 AM
>
> On Mon, 12 Jul 2021 01:22:11 +
> "Tian, Kevin" wrote:
> > > From: Alex Williamson
> > > Sent: Saturday, July 10, 2021 5:51 AM
> > > On Fri, 9 Jul 2021 07:48:44 +
> > > "Tian, Kevin" wrote:
>
> > > > For mdev the
On Mon, 12 Jul 2021 01:22:11 +
"Tian, Kevin" wrote:
> > From: Alex Williamson
> > Sent: Saturday, July 10, 2021 5:51 AM
> > On Fri, 9 Jul 2021 07:48:44 +
> > "Tian, Kevin" wrote:
> > > For mdev the struct device should be the pointer to the parent device.
> >
> > I don't get how
> 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
> > ++
> >
> > /*
> > * Bind a vfio_device to the specified
Hi Kevin,
A couple first pass comments...
On Fri, 9 Jul 2021 07:48:44 +
"Tian, Kevin" wrote:
> 2.2. /dev/vfio device uAPI
> ++
>
> /*
> * Bind a vfio_device to the specified IOMMU fd
> *
> * The user should provide a device cookie when calling this ioctl. The
59 matches
Mail list logo
