From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
Ian Jackson <ian.jackson@eu.citrix.com>,
Wei Liu <wei.liu2@citrix.com>,
xen-devel@lists.xen.org
Subject: Re: [PATCH v2] libxl: disallow PCI device assignment for HVM guest when PoD is enabled
Date: Tue, 14 Jan 2014 14:54:14 +0000 [thread overview]
Message-ID: <52D54F96.2060607@citrix.com> (raw)
In-Reply-To: <1389711014.12434.71.camel@kazak.uk.xensource.com>
On 14/01/14 14:50, Ian Campbell wrote:
> On Mon, 2014-01-13 at 11:52 +0000, Wei Liu wrote:
>> This replicates a Xend behavior, see ec789523749 ("xend: Dis-allow
>> device assignment if PoD is enabled.").
>>
>> This change is restricted to HVM guest, as only HVM is relevant in the
>> counterpart in Xend. We're late in release cycle so the change should
>> only do what's necessary. Probably we can revisit it if we need to do
>> the same thing for PV guest in the future.
>>
>> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
>
> Release hat: The risk here is of a false positive detecting whether PoD
> would be used and therefore refusing to start a domain. However Wei
> directed me earlier on to the code in setup_guest which sets
> XENMEMF_populate_on_demand and I believe it is using the same logic.
>
> The benefit of this is that it will stop people starting a domain in an
> invalid configuration -- but what is the downside here? Is it an
> unhandled IOMMU fault or another host-fatal error? That would make the
> argument for taking this patch pretty strong. On the other hand if the
> failure were simply to kill this domain, that would be a less serious
> issue and I'd be in two minds, mainly due to George not being here to
> confirm that the pod_enabled logic is correct (although if he were here
> I wouldn't be wrestling with this question at all ;-)).
>
> I'm leaning towards taking this fix, but I'd really like to know what
> the current failure case looks like.
>
> Ian.
The answer is likely hardware specific.
An IOMMU fault (however handled by Xen) will result in a master abort on
the DMA transaction for the PCI device which has suffered the fault.
That device can then do anything from continue blindly to issuing an NMI
IOCK/SERR which will likely be fatal to the entire server.
~Andrew
next prev parent reply other threads:[~2014-01-14 14:54 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-13 11:52 [PATCH v2] libxl: disallow PCI device assignment for HVM guest when PoD is enabled Wei Liu
2014-01-14 14:50 ` Ian Campbell
2014-01-14 14:54 ` Andrew Cooper [this message]
2014-01-15 14:12 ` Ian Campbell
2014-01-20 14:04 ` George Dunlap
2014-01-20 14:23 ` Andrew Cooper
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=52D54F96.2060607@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=Ian.Campbell@citrix.com \
--cc=george.dunlap@eu.citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xen.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.