Re: [Xen-devel] Domctl and physdevop for passthrough (Was: Re: Stabilising some tools only HVMOPs?)

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Tue, Mar 01, 2016 at 12:54:09AM -0700, Jan Beulich wrote:
> >>> On 29.02.16 at 19:12, <wei.liu2@xxxxxxxxxx> 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 ...
> 

That would be good. Thank you very much.

Wei.


> Jan
> 

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