|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel][PATCH][VT-d] Dis-allow PCI device assignment if PoD is
To: |
Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx> |
Subject: |
Re: [Xen-devel][PATCH][VT-d] Dis-allow PCI device assignment if PoD is enabled |
From: |
George Dunlap <George.Dunlap@xxxxxxxxxxxxx> |
Date: |
Fri, 22 Jan 2010 12:17:26 +0000 |
Cc: |
"Xu, Dongxiao" <dongxiao.xu@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Han, Weidong" <weidong.han@xxxxxxxxx>, Fraser <Keir.Fraser@xxxxxxxxxxxxx>, "Cui, Dexuan" <dexuan.cui@xxxxxxxxx> |
Delivery-date: |
Fri, 22 Jan 2010 04:17:59 -0800 |
Dkim-signature: |
v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=6mWAlbL+OsKkK3kPwjZL8HdaNTBTIxkYZD2i35FPRmc=; b=vPcBXRb5cAXh9j2J4pTcO1JN561clFD1ixPPdrw+JgdziFH9l87XTsHimpZojAntZ9 fC18JmScYZWFfgvge2CFZy9ORCkzaDq+nRCmClujaqbaYUjRnxWADatPlea4xxTQO+18 kpzX9bPkmwHIFTDvQ3wGwWxI6U1A7Co2QnQCM= |
Domainkey-signature: |
a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=D3tLpTWQQFJN6K0pBJHeK9Q+RUfWXtarPk+Wq52e0bn2jqSRhV2bk/HmIYKIohOR7H JS58vqIInnhVfsq1KvbJLCx6AF8gpLGR04B6WmJZ5ifMCxba13l4TlrS1GneP97ASB9h VEwyOoTS8By5hrjfBSS+NiehMNvZmBCA9bYzk= |
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
In-reply-to: |
<4FA716B1526C7C4DB0375C6DADBC4EA342A82FAB47@xxxxxxxxxxxxxxxxxxxxxxxxx> |
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> <4FA716B1526C7C4DB0375C6DADBC4EA342A82FAB47@xxxxxxxxxxxxxxxxxxxxxxxxx> |
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
On Thu, Jan 21, 2010 at 6:02 PM, Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx> wrote:
> 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.
At the moment, I can't imagine how IOMMU/VT-d can interact well with
PoD during boot, before the balloon driver gets in and does its thing.
It's guaranteed during that time that a high percentage of the memory
which the guest thinks it has free will be not-present in the p2m.
There's no way we can predict which gfns will be passed to the device;
having been zeroed (and thus populated) is no help, since a
non-negligible percentage of zeroed pages will need to be reclaimed
for the PoD pool again anyway.
If it really is true that devices aren't used during boot, then we
could simply have the balloon driver / the tools do a final "sync"
once the "target" has been reached (and outstanding PoD entries ==
size of PoD memory pool). Doing more than that (say, syncing on every
p2m update) doesn't solve the problem (although I suppose it may be
necessary to prevent corruption).
-George
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|