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/
Home Products Support Community News


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

To: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>, "Xu, Dongxiao" <dongxiao.xu@xxxxxxxxx>
Subject: RE: [Xen-devel][PATCH][VT-d] Dis-allow PCI device assignment if PoD is enabled
From: Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>
Date: Thu, 21 Jan 2010 18:02:42 +0000
Accept-language: en-US
Acceptlanguage: en-US
Cc: Ian, "Cui, Dexuan" <dexuan.cui@xxxxxxxxx>, "Han, Weidong" <weidong.han@xxxxxxxxx>, Pratt <Ian.Pratt@xxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Fraser <Keir.Fraser@xxxxxxxxxxxxx>, Keir
Delivery-date: Thu, 21 Jan 2010 10:03:33 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4B585A7D.9000905@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <6CADD16F56BC954D8E28F3836FA7ED711313B899A0@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4B585A7D.9000905@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcqaoCe10d0hyid7RaekwdljMIR64QAIwo2A
Thread-topic: [Xen-devel][PATCH][VT-d] Dis-allow PCI device assignment if PoD is enabled
> 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.



Xen-devel mailing list