RE: [Xen-devel][PATCH][VT-d] Dis-allow PCI device assignment if PoD is enabled

[Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>]

> Looking forward, what would it take to make PoD and VT-d coexist?  We
> only need PoD during boot, until the balloon driver comes up and
> balloons down the guest's memory.  Three solutions come to mind, but as
> I don't know the constraints of VT-d, I don't know which is feasible (if
> any):
> * Redo the VT-d mapping every time the p2m map changes as a result of PoD.
> * While PoD pages exist, intercept device commands, and redo the VT-d
> map if the page was marked PoD the last time we updated the VT-d map
> * Detect DMA faults, instantiate the page if necessary, update the VT-d
> map, and re-start the transaction.
> 
> How expensive is it to change the VT-d pagetable?  Is a DMA fault
> re-startable?  i.e., could we take a fault, redo the VT-d map, and
> re-issue the DMA request?

IOMMU faults are not restartable, at least currently.

Flushing the IOTLB is very expensive. Fortunately -ve entries are not cached, 
and since PoD mainly adds new mappings we should be fine. The zeroed page 
reclaimation stuff is a bit more dicey and would require syncrhonization 
against an IOTLB flush before returning the pages to xen.

In many/most cases the device will not be in use that early in boot, so it's a 
bit annoying to have to do maintain the IOMMU pagetables through PoD, but 
unavoidable. The key thing is that we only have to do it for domains that 
actually have devices passed-through.

Ian

 



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