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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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.

Jan

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