Re: Proposal for virtual IOMMU binding b/w vIOMMU and passthrough devices

[Juergen Gross <jgross@xxxxxxxx>]

On 02.11.22 09:50, Bertrand Marquis wrote:
> Hi Elliott,
>
> > On 1 Nov 2022, at 20:25, Elliott Mitchell <ehem+xen@xxxxxxx> wrote:
> >
> > On Tue, Nov 01, 2022 at 04:30:31PM +0000, Bertrand Marquis wrote:
> > > > On 1 Nov 2022, at 15:01, Elliott Mitchell <ehem+xen@xxxxxxx> wrote:
> > > >
> > > > On Mon, Oct 31, 2022 at 01:26:44PM +0000, Bertrand Marquis wrote:
> > > > > > On 30 Oct 2022, at 21:14, Stefano Stabellini <sstabellini@xxxxxxxxxx> wrote:
> > > > > >
> > > > > > Ideally this would be something quick that can be easily invoked as the
> > > > > > first step of an external third-party build process.
> > > > > I think that we are making this problem a lot to complex and I am not sure
> > > > > that all this complexity is required.
> > > > Speaking of complexity.  Is it just me or does a vIOMMU had an odd sort
> > > > of similarity with a Grant Table?
> > > >
> > > > Both are about allowing foreign entities access to portions of the
> > > > current domain's memory.  Just in the case of a Grant Table the entity
> > > > happens to be another domain, whereas for a vIOMMU it is a hardware
> > > > device.
> > > >
> > > > Perhaps some functionality could be shared between the two?  Perhaps
> > > > this is something for the designer of the next version of IOMMU to think
> > > > about?  (or perhaps I'm off the deep end and bringing in a silly idea)
> > > I am not quite sure what you mean here.
> > >
> > > The IOMMU is something not Xen specific. Linux is using it to restrict the area
> > > of memory accessible to a device using its DMA engine. Here we just try to give
> > > the same possibility when running on top Xen in a transparent way so that the
> > > Linux (or an other guest) can continue to do the same even if it is running on
> > > top of Xen.
> > > In practice, the guest is not telling us what it does, we just get the pointer 
> > > to the
> > > first level of page table and we write it in the hardware which is doing the 
> > > rest.
> > > We need to have a vIOMMU because we need to make sure the guest is only
> > > doing this for devices assigned to him and that it is not modifying the second
> > > level of page tables which is used by Xen to make sure that only the memory
> > > from the guest is accessible using the DMA engine.
> > >
> > > So I am not exactly seeing the common part with grant tables here.
> > With Grant Tables, one domain is allocating pages and then allowing
> > another domain to read and potentially write to them.  What is being
> > given to Xen is the tuple of page address and other domain.
> With the IOMMU we do not get to that information, we only get the first level of
> page table pointer and the hardware is doing the rest, protecting the access
> using the second level of page tables handled by Xen.
>
> > With the model presently being discussed you would have a vIOMMU for each
> > other domain.  The the pages access is being granted to are the pages
> > being entered into the vIOMMU page table.
> Which Xen does not check.
>
> > Allocate a domain Id to each IOMMU domain and this very much seems quite
> > similar to Xen's grant tables.  I'm unsure the two can be unified, but
> > they appear to have many common aspects.
> > From an high level point of view it might but from the guest point of view the
> IOMMU is something used with or without Xen where grant tables are very
> specific to Xen. I do not see anything that could be unified there.
>
> Maybe I am missing something here that other could see though :-)
You might want to have a look at my "Grant table V3" design session at the
Xen Summit this year:

https://lists.xen.org/archives/html/xen-devel/2022-09/msg01429.html


Juergen

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature