WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Dom0 hypercall for adding and removing PCI devices

[Keir Fraser]
> On 23/7/08 10:26, "Han, Weidong" <weidong.han@xxxxxxxxx> wrote:
>>> So this would be one extra VT-d pagetable, for the whole system,
>>> which would be the fallback location for RMRR mappings for devices
>>> which are currently not assigned to any domain? Thus allowing
>>> firmware to successfully initiate DMA operations on those devices?
>>> Sounds sensible.

Well, the VT-d page table for RMRR devices need not contain the whole
system memory---only those regions specified in the DMAR tables.

>> Is it possible that idle_domain owns the RMRR VT-d page table?

> If that's a convenient place to stash it then why not? Either way,
> seems you're going to have it special-cased in the code as fallback
> owner for unassigned devices. It's possible that having it stashed
> in the idle domain will simply make the code more confusing. I'm not
> sure though.

Right.  I don't see any particular good reason to associate it with
the idle domain.  As noted above, the page table need not even cover
the whole memory, and it will never change after being set up at boot
time.  If special case code is needed anyway, then one might as well
install a custom VT-d page table.

If supported by hardware, the extra page tables can even be skipped
altogether and the device marked as having passthrough access.  That
would give the RMRR device complete access to system memory, though.

        eSk




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel