From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper 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 Message-ID: <52DD314F.9060606@citrix.com> References: <1389613948-5774-1-git-send-email-wei.liu2@citrix.com> <1389711014.12434.71.camel@kazak.uk.xensource.com> <52D54F96.2060607@citrix.com> <52DD2CDC.8030705@eu.citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <52DD2CDC.8030705@eu.citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: George Dunlap Cc: Ian Jackson , Wei Liu , Ian Campbell , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org 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 >>> Acked-by: Ian Campbell >>> >>> 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