Re: [Xen-devel] [PATCH v3] x86/ept: Allow write-combining on !mfn_valid() MMIO mappings again

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: Thursday, January 26, 2017 11:48 PM
> 
> >>> On 26.01.17 at 15:50, <dwmw2@xxxxxxxxxxxxx> wrote:
> > From: David Woodhouse <dwmw@xxxxxxxxxx>
> >
> > For some MMIO regions, such as those high above RAM, mfn_valid() will
> > return false.
> >
> > Since the fix for XSA-154 in commit c61a6f74f80e ("x86: enforce
> > consistent cachability of MMIO mappings"), guests have no longer been
> > able to use PAT to obtain write-combining on such regions because the
> > 'ignore PAT' bit is set in EPT.
> >
> > We probably want to err on the side of caution and preserve that
> > behaviour for addresses in mmio_ro_ranges, but not for normal MMIO
> > mappings. That necessitates a slight refactoring to check mfn_valid()
> > later, and let the MMIO case get through to the right code path.
> >
> > Since we're not bailing out for !mfn_valid() immediately, the range
> > checks need to be adjusted to cope — simply by masking in the low bits
> > to account for 'order' instead of adding, to avoid overflow when the mfn
> > is INVALID_MFN (which happens on unmap, since we carefully call this
> > function to fill in the EMT even though the PTE won't be valid).
> >
> > The range checks are also slightly refactored to put only one of them in
> > the fast path in the common case. If it doesn't overlap, then it
> > *definitely* isn't contained, so we don't need both checks. And if it
> > overlaps and is only one page, then it definitely *is* contained.
> >
> > Finally, add a comment clarifying how that 'return -1' works — it isn't
> > returning an error and causing the mapping to fail; it relies on
> > resolve_misconfig() being able to split the mapping later. So it's
> > *only* sane to do it where order>0 and the 'problem' will be solved by
> > splitting the large page. Not for blindly returning 'error', which I was
> > tempted to do in my first attempt.
> >
> > Signed-off-by: David Woodhouse <dwmw@xxxxxxxxxx>
> 
> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
> 
> But before committing I'd prefer to have a VMX maintainer ack
> too.
> 

Reviewed-by: Kevin Tian <kevin.tian@xxxxxxxxx>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel