> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Thursday, January 26, 2017 11:48 PM > > >>> 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. >
Reviewed-by: Kevin Tian <kevin.t...@intel.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
