[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d8bb795f-8d73-e9a5-a4b1-8d9c563dffbd@redhat.com>
Date: Wed, 2 Jun 2021 16:58:13 +0800
From: Jason Wang <jasowang@...hat.com>
To: Jason Gunthorpe <jgg@...dia.com>
Cc: "Tian, Kevin" <kevin.tian@...el.com>,
Lu Baolu <baolu.lu@...ux.intel.com>,
Liu Yi L <yi.l.liu@...ux.intel.com>,
"Alex Williamson (alex.williamson@...hat.com)\"\""
<alex.williamson@...hat.com>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
Jonathan Corbet <corbet@....net>,
LKML <linux-kernel@...r.kernel.org>,
"iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
David Woodhouse <dwmw2@...radead.org>
Subject: Re: [RFC] /dev/ioasid uAPI proposal
在 2021/6/2 上午1:29, Jason Gunthorpe 写道:
> 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 a good fit.
>
> Further there are global container wide properties that are hard to
> carry over to a multi-FD model, like the attachment of devices to the
> container at the startup.
So if we implement per fd model. The global "container" properties could
be done via the parent fd. E.g attaching the parent to the device at the
startup.
>
>>> So this RFC treats fd as a container of address spaces which is each
>>> tagged by an IOASID.
>> If the container and address space is 1:1 then the container seems useless.
> The examples at the bottom of the document show multiple IOASIDs in
> the container for a parent/child type relationship
This can also be done per fd? A fd parent can have multiple fd childs.
Thanks
>
> Jason
>
Powered by blists - more mailing lists