[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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 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.

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.


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg@xxxxxxx  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445





 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.