>>> On 26.01.17 at 15:50, <dw...@infradead.org> wrote: > From: David Woodhouse <d...@amazon.com> > > 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 <d...@amazon.com>
Reviewed-by: Jan Beulich <jbeul...@suse.com> But before committing I'd prefer to have a VMX maintainer ack too. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel