[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v2] libxl: disallow PCI device assignment for HVM guest when PoD is enabled



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@xxxxxxxxxx>
>>> Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
>>>
>>> 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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.