Re: Domctl and physdevop for passthrough (Was: Re: Stabilising some tools only HVMOPs?)

From: "Jan Beulich" <JBeulich@suse.com>
To: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	PaulDurrant <Paul.Durrant@citrix.com>,
	Anthony PERARD <anthony.perard@citrix.com>,
	Xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: Domctl and physdevop for passthrough (Was: Re: Stabilising some tools only HVMOPs?)
Date: Tue, 01 Mar 2016 00:54:09 -0700	[thread overview]
Message-ID: <56D558B202000078000D7A6F@prv-mh.provo.novell.com> (raw)
In-Reply-To: <20160229181236.GI17111@citrix.com>

>>> On 29.02.16 at 19:12, <wei.liu2@citrix.com> wrote:
> I read the XSA-154 patch and think a little bit on whether making
> dedicated hypercall is feasible.
> 
> 1. The patch for XSA-154 mentions that only MMIO mappings with
>    inconsistent attributes can cause system instability.
> 2. PV case is hard, but the device model library is only of interest to
>    HVM domain, so PV can be ignored.
> 3. We want to continue honoring pinned cachability attributes for HVM
>    domain.
> 
> It seems we have a way forward. Say, we have new hypercall just for
> pinning video ram cachability attribute.
> 
> The new hypercall has following properties:
> 
> 1. It can only be used on HVM domains.
> 2. It can only be used on mfns that are not in MMIO ranges, because
>    vram is just normal ram.
> 3. It can only set the cachability attribute to WC (used by video ram).
> 4. It is not considered stable.
> 
> so that it won't be abused to change cachability attributes of MMIO
> mappings on PV guest to make the host unstable. The stale data issue is
> of no relevance as stated in XSA-154 patch.
> 
> Does this sound plausible?

Yes, it does, but it extends our dependency on what we've been
told in the context of XSA-154 is actually true (and has been true
for all earlier processor generations, and will continue to be true
in the future). But then I don't immediately see why the existing
pinning operation won't suffice: It's a domctl (i.e. we can change
it), you say you don't need it to be stable, and it's already
documented as being intended for RAM only (albeit iirc that's not
getting enforced anywhere right now). The main present
problem (which I don't see a new hypercall to solve) is that it's
GFN-based, and the GFN->MFN mapping can change after such
pinning got established. Otoh I think that by changing the
placement of the hvm_get_mem_pinned_cacheattr() calls we
could enforce the RAM-only aspect quite easily. Let me put
together a patch ...

Jan

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