From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Ian Pratt <Ian.Pratt@eu.citrix.com>
Cc: "Xu, Dongxiao" <dongxiao.xu@intel.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
"Han, Weidong" <weidong.han@intel.com>,
Fraser <Keir.Fraser@eu.citrix.com>,
"Cui, Dexuan" <dexuan.cui@intel.com>
Subject: Re: [PATCH][VT-d] Dis-allow PCI device assignment if PoD is enabled
Date: Fri, 22 Jan 2010 12:17:26 +0000 [thread overview]
Message-ID: <de76405a1001220417p7ea24e30nde43f7cec460ac2@mail.gmail.com> (raw)
In-Reply-To: <4FA716B1526C7C4DB0375C6DADBC4EA342A82FAB47@LONPMAILBOX01.citrite.net>
On Thu, Jan 21, 2010 at 6:02 PM, Ian Pratt <Ian.Pratt@eu.citrix.com> 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
prev parent reply other threads:[~2010-01-22 12:17 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-21 12:28 [PATCH][VT-d] Dis-allow PCI device assignment if PoD is enabled Xu, Dongxiao
2010-01-21 13:45 ` George Dunlap
2010-01-21 18:02 ` Ian Pratt
2010-01-22 12:17 ` George Dunlap [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=de76405a1001220417p7ea24e30nde43f7cec460ac2@mail.gmail.com \
--to=george.dunlap@eu.citrix.com \
--cc=Ian.Pratt@eu.citrix.com \
--cc=Keir.Fraser@eu.citrix.com \
--cc=dexuan.cui@intel.com \
--cc=dongxiao.xu@intel.com \
--cc=weidong.han@intel.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).