All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: George Dunlap <george.dunlap@eu.citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [PATCH v2] libxl: disallow PCI device assignment for HVM guest when PoD is enabled
Date: Mon, 20 Jan 2014 14:23:11 +0000	[thread overview]
Message-ID: <52DD314F.9060606@citrix.com> (raw)
In-Reply-To: <52DD2CDC.8030705@eu.citrix.com>

On 20/01/14 14:04, George Dunlap wrote:
> On 01/14/2014 02:54 PM, Andrew Cooper wrote:
>> 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.
>
> I thought we changed the behavior of Xen not to crash on SERR?  Or was
> I confused about that?
>
> Since a VM should be able to craft a DMA pointing to invalid p2m space
> fairly easily, it seems like having the host crash in that scenario
> would basically remove half of the reason for having am IOMMU in the
> first place.
>
>  -George

The behaviour of IOCK/SERR NMIs depends on the "nmi=" command line
option, which for a non-debug build is "redirect to dom0", and in a
debug build is fatal.  Dom0's behaviour is normally to say "huh - my
virtual environment looks fine", which makes it the option quite useless.

IOCK/SERR NMIs can be out-of-band, possibly via the BMC on a server
class motherboard, and per XSA-59, possibly not caught by the IOMMU.

~Andrew

      reply	other threads:[~2014-01-20 14:23 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
2014-01-15 14:12     ` Ian Campbell
2014-01-20 14:04     ` George Dunlap
2014-01-20 14:23       ` Andrew Cooper [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=52DD314F.9060606@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.