[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |