[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v3] x86/ept: Allow write-combining on !mfn_valid() MMIO mappings again
> 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |