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

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


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>