On Fri, May 28, 2021 at 08:36:49PM -0300, Jason Gunthorpe wrote:
> On Thu, May 27, 2021 at 07:58:12AM +, Tian, Kevin wrote:
>
> > 2.1. /dev/ioasid uAPI
> > +
> >
> > /*
> > * Check whether an uAPI extension is supported.
> > *
> > * This is for FD-level capabilities, su
On Fri, May 28, 2021 at 02:35:38PM -0300, Jason Gunthorpe wrote:
> On Thu, May 27, 2021 at 07:58:12AM +, Tian, Kevin wrote:
[snip]
> > With above design /dev/ioasid uAPI is all about I/O address spaces.
> > It doesn't include any device routing information, which is only
> > indirectly regist
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 frameworks (VFIO, vDPA,
> etc.) are expected to use this interface instead of creating their own logic
> t
On Fri, May 28, 2021 at 04:58:39PM -0300, Jason Gunthorpe wrote:
> 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 listed under /dev/vfio thus a device fd can b
On Tue, Jun 01, 2021 at 02:56:43PM -0300, Jason Gunthorpe wrote:
> 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 +, Tian, Kevin wrote:
> > > >
> > > > 5. Use Ca
On 2021/6/2 1:33, Jason Gunthorpe wrote:
> On Tue, Jun 01, 2021 at 08:30:35PM +0800, Lu Baolu wrote:
>
>> The drivers register per page table fault handlers to /dev/ioasid which
>> will then register itself to iommu core to listen and route the per-
>> device I/O page faults.
>
> I'm still confu
On 6/2/21 1:26 AM, Jason Gunthorpe wrote:
On Tue, Jun 01, 2021 at 07:09:21PM +0800, Lu Baolu wrote:
This version only covers 1) and 4). Do you think we need to support 2),
3) and beyond?
Yes aboslutely. The API should be flexable enough to specify the
creation of all future page table formats
> From: Alex Williamson
> Sent: Wednesday, June 2, 2021 6:22 AM
>
> On Tue, 1 Jun 2021 07:01:57 +
> "Tian, Kevin" wrote:
> >
> > I summarized five opens here, about:
> >
> > 1) Finalizing the name to replace /dev/ioasid;
> > 2) Whether one device is allowed to bind to multiple IOASID fd's;
> 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 +, Tian, Kevin wrote:
> > > >
> > > > 5. Use
> 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:12AM +, Tian, Kevin wrote:
> > >
> > > > IOASID ne
> 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:12AM +, Tian, Kevin wrote:
> > > > /dev/ioasid pro
On Tue, 1 Jun 2021 07:01:57 +
"Tian, Kevin" wrote:
>
> I summarized five opens here, about:
>
> 1) Finalizing the name to replace /dev/ioasid;
> 2) Whether one device is allowed to bind to multiple IOASID fd's;
> 3) Carry device information in invalidation/fault reporting uAPI;
> 4) What
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:12AM +, Tian, Kevin wrote:
> > > /dev/ioasid provides an unified interface for managing I/O page tables for
> > > devices assig
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 +, Tian, Kevin wrote:
> > >
> > > 5. Use Cases and Flows
> > >
> > > Here assume VFIO will support a new model where every
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:12AM +, Tian, Kevin wrote:
> >
> > > IOASID nesting can be implemented in two ways: hardware nesting and
> > > software nestin
On Tue, Jun 01, 2021 at 12:04:00PM +, Parav Pandit wrote:
>
>
> > From: Jason Gunthorpe
> > Sent: Monday, May 31, 2021 11:43 PM
> >
> > On Mon, May 31, 2021 at 05:37:35PM +, Parav Pandit wrote:
> >
> > > In that case, can it be a new system call? Why does it have to be under
> > /dev/i
On Tue, Jun 01, 2021 at 08:30:35PM +0800, Lu Baolu wrote:
> The drivers register per page table fault handlers to /dev/ioasid which
> will then register itself to iommu core to listen and route the per-
> device I/O page faults.
I'm still confused why drivers need fault handlers at all?
Jason
_
On Tue, Jun 01, 2021 at 04:47:15PM +0800, Jason Wang wrote:
> We can open up to ~0U file descriptors, I don't see why we need to restrict
> it in uAPI.
There are significant problems with such large file descriptor
tables. High FD numbers man things like select don't work at all
anymore and IIRC
> From: Tian, Kevin
> Sent: Thursday, May 27, 2021 1:28 PM
> 5.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).
>
> - Host IOMMU driver receives a page request with raw fault_data {rid,
On Tue, Jun 01, 2021 at 02:07:05PM +0800, Jason Wang wrote:
> For the case of 1M, I would like to know what's the use case for a single
> process to handle 1M+ address spaces?
For some scenarios every guest PASID will require a IOASID ID # so
there is a large enough demand that FDs alone are not
On Tue, Jun 01, 2021 at 07:09:21PM +0800, Lu Baolu wrote:
> This version only covers 1) and 4). Do you think we need to support 2),
> 3) and beyond?
Yes aboslutely. The API should be flexable enough to specify the
creation of all future page table formats we'd want to have and all HW
specific de
On Tue, Jun 01, 2021 at 11:08:53AM +0800, Lu Baolu wrote:
> On 6/1/21 2:09 AM, Jason Gunthorpe wrote:
> > > > device bind should fail if the device somehow isn't compatible with
> > > > the scheme the user is tring to use.
> > > yeah, I guess you mean to fail the device attach when the IOASID is a
On 2021/6/1 20:30, Lu Baolu wrote:
> On 2021/6/1 15:15, Shenming Lu wrote:
>> On 2021/6/1 13:10, Lu Baolu wrote:
>>> Hi Shenming,
>>>
>>> On 6/1/21 12:31 PM, Shenming Lu wrote:
On 2021/5/27 15:58, Tian, Kevin wrote:
> /dev/ioasid provides an unified interface for managing I/O page tables f
On 2021/6/1 15:15, Shenming Lu wrote:
On 2021/6/1 13:10, Lu Baolu wrote:
Hi Shenming,
On 6/1/21 12:31 PM, Shenming Lu wrote:
On 2021/5/27 15:58, Tian, Kevin wrote:
/dev/ioasid provides an unified interface for managing I/O page tables for
devices assigned to userspace. Device passthrough fram
> From: Jason Gunthorpe
> Sent: Monday, May 31, 2021 11:43 PM
>
> On Mon, May 31, 2021 at 05:37:35PM +, Parav Pandit wrote:
>
> > In that case, can it be a new system call? Why does it have to be under
> /dev/ioasid?
> > For example few years back such system call mpin() thought was propo
Hi Jason,
On 2021/5/29 7:36, Jason Gunthorpe wrote:
/*
* Bind an user-managed I/O page table with the IOMMU
*
* Because user page table is untrusted, IOASID nesting must be enabled
* for this ioasid so the kernel can enforce its DMA isolation policy
* through the parent ioasid.
在 2021/6/1 下午2:16, Tian, Kevin 写道:
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,
On 6/1/21 1:08 PM, Jason Wang wrote:
2) If yes, what's the reason for
> 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 listed under /dev/vfio thus a device fd can b
> 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 parent I/O page
> > tables are walke
> 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.
On 2021/6/1 13:10, Lu Baolu wrote:
> Hi Shenming,
>
> On 6/1/21 12:31 PM, Shenming Lu wrote:
>> On 2021/5/27 15:58, Tian, Kevin wrote:
>>> /dev/ioasid provides an unified interface for managing I/O page tables for
>>> devices assigned to userspace. Device passthrough frameworks (VFIO, vDPA,
>>> et
> 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 frameworks (VFIO,
> vDPA,
> > etc.)
> 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,
> >>>
> >>> On 6/1/21 1:08 PM, Jason Wang wrote:
> >> 2) If yes, what's the
在 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,
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) a
> 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
在 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
happens
if we call GET_INFO for the ioasid_fd?
3) If not, how GET_INFO work?
oh
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 happens
if we call GET_INFO for the ioasid_fd?
3) If not, how GET_INFO work?
oh, missed this question in prior repl
Hi Shenming,
On 6/1/21 12:31 PM, Shenming Lu wrote:
On 2021/5/27 15:58, Tian, Kevin wrote:
/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 cre
在 2021/6/1 下午12:27, Shenming Lu 写道:
On 2021/6/1 10:36, Jason Wang wrote:
在 2021/5/31 下�4:41, Liu Yi L 写�:
I guess VFIO_ATTACH_IOASID will fail if the underlayer doesn't support
hardware nesting. Or is there way to detect the capability before?
I think it could fail in the IOASID_CRE
在 2021/6/1 上午11:31, Liu Yi L 写道:
On Tue, 1 Jun 2021 10:36:36 +0800, Jason Wang wrote:
在 2021/5/31 下午4:41, Liu Yi L 写道:
I guess VFIO_ATTACH_IOASID will fail if the underlayer doesn't support
hardware nesting. Or is there way to detect the capability before?
I think it could fail in the IOASID
On 2021/5/27 15:58, Tian, Kevin wrote:
> /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
On 2021/6/1 10:36, Jason Wang wrote:
>
> 在 2021/5/31 下午4:41, Liu Yi L 写道:
>>> I guess VFIO_ATTACH_IOASID will fail if the underlayer doesn't support
>>> hardware nesting. Or is there way to detect the capability before?
>> I think it could fail in the IOASID_CREATE_NESTING. If the gpa_ioasid
>> is
On Tue, 1 Jun 2021 10:36:36 +0800, Jason Wang wrote:
> 在 2021/5/31 下午4:41, Liu Yi L 写道:
> >> I guess VFIO_ATTACH_IOASID will fail if the underlayer doesn't support
> >> hardware nesting. Or is there way to detect the capability before?
> > I think it could fail in the IOASID_CREATE_NESTING. If t
On 6/1/21 2:09 AM, Jason Gunthorpe wrote:
device bind should fail if the device somehow isn't compatible with
the scheme the user is tring to use.
yeah, I guess you mean to fail the device attach when the IOASID is a
nesting IOASID but the device is behind an iommu without nesting support.
right
在 2021/5/31 下午4:41, Liu Yi L 写道:
I guess VFIO_ATTACH_IOASID will fail if the underlayer doesn't support
hardware nesting. Or is there way to detect the capability before?
I think it could fail in the IOASID_CREATE_NESTING. If the gpa_ioasid
is not able to support nesting, then should fail it.
On 5/31/21 7:31 PM, Liu Yi L wrote:
On Fri, 28 May 2021 20:36:49 -0300, Jason Gunthorpe wrote:
On Thu, May 27, 2021 at 07:58:12AM +, Tian, Kevin wrote:
2.1. /dev/ioasid uAPI
+
[---cut for short---]
/*
* Allocate an IOASID.
*
* IOASID is the FD-local software h
On Mon, May 31, 2021 at 05:37:35PM +, Parav Pandit wrote:
> In that case, can it be a new system call? Why does it have to be under
> /dev/ioasid?
> For example few years back such system call mpin() thought was proposed in
> [1].
Reference counting of the overall pins are required
So when
On Mon, May 31, 2021 at 07:31:57PM +0800, Liu Yi L wrote:
> > > /*
> > > * Get information about an I/O address space
> > > *
> > > * Supported capabilities:
> > > * - VFIO type1 map/unmap;
> > > * - pgtable/pasid_table binding
> > > * - hardware nesting vs. software n
> From: Tian, Kevin
> Sent: Thursday, May 27, 2021 1:28 PM
> /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
> t
On Fri, 28 May 2021 20:36:49 -0300, Jason Gunthorpe wrote:
> On Thu, May 27, 2021 at 07:58:12AM +, Tian, Kevin wrote:
>
> > 2.1. /dev/ioasid uAPI
> > +
> >
> > /*
> > * Check whether an uAPI extension is supported.
> > *
> > * This is for FD-level capabilities, such as
On Fri, 28 May 2021 10:24:56 +0800, Jason Wang wrote:
> 在 2021/5/27 下午3:58, Tian, Kevin 写道:
> > /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 inst
On Thu, May 27, 2021 at 07:58:12AM +, Tian, Kevin wrote:
> 2.1. /dev/ioasid uAPI
> +
>
> /*
> * Check whether an uAPI extension is supported.
> *
> * This is for FD-level capabilities, such as locked page pre-registration.
> * IOASID-level capabilities are reported t
On Fri, May 28, 2021 at 10:24:56AM +0800, Jason Wang wrote:
> > 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.
> > When it's
On Fri, May 28, 2021 at 06:23:07PM +0200, Jean-Philippe Brucker wrote:
> Regarding the invalidation, I think limiting it to IOASID may work but it
> does bother me that we can't directly forward all invalidations received
> on the vIOMMU: if the guest sends a device-wide invalidation, do we
> iter
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 frameworks (VFIO, vDPA,
> etc.) are expected to use this interface instead of creating their own logic
> t
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 listed under /dev/vfio thus a device fd can be acquired w/o
> going through legacy container/group interface. For illustr
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 parent I/O page
> tables are walked consecutively by the IOMMU to form a nested translation.
> When it's imp
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 frameworks (VFIO, vDPA,
> etc.) are expected to use this interface instead of creating their own logic
> t
在 2021/5/27 下午3:58, Tian, Kevin 写道:
/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 i
201 - 259 of 259 matches
Mail list logo
