From patchwork Thu Jan 26 12:39:06 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: David Woodhouse X-Patchwork-Id: 9539199 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id AC9DD604A0 for ; Thu, 26 Jan 2017 12:42:06 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 969B2201BC for ; Thu, 26 Jan 2017 12:42:06 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 8B71E2819A; Thu, 26 Jan 2017 12:42:06 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id E50F2201BC for ; Thu, 26 Jan 2017 12:42:05 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cWjKk-0002xw-TA; Thu, 26 Jan 2017 12:39:22 +0000 Received: from mail6.bemta6.messagelabs.com ([193.109.254.103]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cWjKj-0002xq-Ts for xen-devel@lists.xen.org; Thu, 26 Jan 2017 12:39:22 +0000 Received: from [85.158.143.35] by server-10.bemta-6.messagelabs.com id 5B/4D-13192-9FDE9885; Thu, 26 Jan 2017 12:39:21 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPIsWRWlGSWpSXmKPExsUSNTvmou73t50 RBmvb5SyWfFzM4sDocXT3b6YAxijWzLyk/IoE1oxl744xFWyOqvhx8x9LA+PG0C5GTg4hgfWM ErueF4HYvAKmEi86bjGD2MIC4RJTJ3ezgdhsAtoSB3acZAGxRQSUJXp//QazmQWKJS41nmYCs TkF7CUeXljA2sXIBTTzI6PEhw0/2SGKaiXOvX0LNpRFQFVixfcmoCIOoGWCEn93CIOEJQQ0JB 62rGOEsNsYJe6ttpvAyDsLSfcshA6IsKZE6/bf7BC2tsSyha+ZIWxbif1XV0LZphKvj35khLA VJaZ0P2RfwMi+ilG9OLWoLLVI11QvqSgzPaMkNzEzR9fQwEwvN7W4ODE9NScxqVgvOT93EyMw YBmAYAfj9Mv+hxglOZiURHlvandGCPEl5adUZiQWZ8QXleakFh9ilOHgUJLglQBGgJBgUWp6a kVaZg4wdmDSEhw8SiK8O98ApXmLCxJzizPTIVKnGBWlxHmXgSQEQBIZpXlwbbB4vcQoKyXMyw h0iBBPQWpRbmYJqvwrRnEORiVhXkOQ7TyZeSVw018BLWYCWnyBuR1kcUkiQkqqgXG3WB2bbfH SxBC3D8J//WZO6giZtqdvL3fGlwazpUfPzg1cl9b6qiqaiWt/zNK245vKS1cliua0szm8/l/7 tv/iPqXnAu+n/yt+5yvc+CBsdWHyB6YA4XSbpr2Ju7btO7771rHXu42Yf89/eWrO5JoO7w8Vj bkc519ZNn+XTqkMeLxkcfUrUX4lluKMREMt5qLiRABlz+Gn0gIAAA== X-Env-Sender: BATV+b0eccc5b516484db75e9+4904+infradead.org+dwmw2@twosheds .srs.infradead.org X-Msg-Ref: server-6.tower-21.messagelabs.com!1485434359!31586161!1 X-Originating-IP: [90.155.92.209] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 9.1.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15749 invoked from network); 26 Jan 2017 12:39:19 -0000 Received: from twosheds.infradead.org (HELO twosheds.infradead.org) (90.155.92.209) by server-6.tower-21.messagelabs.com with AES256-GCM-SHA384 encrypted SMTP; 26 Jan 2017 12:39:19 -0000 Received: from [2001:8b0:10b:1:24d1:3b98:1f63:c8d] by twosheds.infradead.org with esmtpsa (Exim 4.87 #1 (Red Hat Linux)) id 1cWjKV-0000JN-Bq; Thu, 26 Jan 2017 12:39:07 +0000 Message-ID: <1485434346.4727.182.camel@infradead.org> From: David Woodhouse To: Jan Beulich In-Reply-To: <5889E1690200007800134264@prv-mh.provo.novell.com> References: <1485353329.4727.111.camel@infradead.org> <5888C2810200007800133CDC@prv-mh.provo.novell.com> <1485421042.4727.173.camel@infradead.org> <5889E1690200007800134264@prv-mh.provo.novell.com> Date: Thu, 26 Jan 2017 12:39:06 +0000 Mime-Version: 1.0 X-Mailer: Evolution 3.18.5.2-0ubuntu3.1 X-SRS-Rewrite: SMTP reverse-path rewritten from by twosheds.infradead.org. See http://www.infradead.org/rpr.html Cc: Andrew Cooper , "H. Peter Anvin" , xen-devel@lists.xen.org Subject: [Xen-devel] [PATCH v2] x86/ept: Allow write-combining on !mfn_valid() MMIO mappings again X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" X-Virus-Scanned: ClamAV using ClamSMTP From: David Woodhouse 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 ---  xen/arch/x86/hvm/mtrr.c | 26 +++++++++++++++++---------  1 file changed, 17 insertions(+), 9 deletions(-) --  2.7.4 diff --git a/xen/arch/x86/hvm/mtrr.c b/xen/arch/x86/hvm/mtrr.c index 709759c..41ae8b4 100644 --- a/xen/arch/x86/hvm/mtrr.c +++ b/xen/arch/x86/hvm/mtrr.c @@ -773,18 +773,20 @@ int epte_get_entry_emt(struct domain *d, unsigned long gfn, mfn_t mfn,      if ( v->domain != d )          v = d->vcpu ? d->vcpu[0] : NULL;   -    if ( !mfn_valid(mfn_x(mfn)) || -         rangeset_contains_range(mmio_ro_ranges, mfn_x(mfn), -                                 mfn_x(mfn) + (1UL << order) - 1) ) +    /* Mask, not add, for order so it works with INVALID_MFN on unmapping */ +    if ( rangeset_overlaps_range(mmio_ro_ranges, mfn_x(mfn), +  mfn_x(mfn) | ((1UL << order) - 1)) )      { -        *ipat = 1; -        return MTRR_TYPE_UNCACHABLE; + if ( !order || rangeset_contains_range(mmio_ro_ranges, mfn_x(mfn), +        mfn_x(mfn) | ((1UL << order) - 1)) ) + { +     *ipat = 1; +     return MTRR_TYPE_UNCACHABLE; + } + /* Force invalid memory type so resolve_misconfig() will split it */ + return -1;      }   -    if ( rangeset_overlaps_range(mmio_ro_ranges, mfn_x(mfn), -                                 mfn_x(mfn) + (1UL << order) - 1) ) -        return -1; -      if ( direct_mmio )      {          if ( (mfn_x(mfn) ^ d->arch.hvm_domain.vmx.apic_access_mfn) >> order ) @@ -795,6 +797,12 @@ int epte_get_entry_emt(struct domain *d, unsigned long gfn, mfn_t mfn,          return MTRR_TYPE_WRBACK;      }   +    if ( !mfn_valid(mfn_x(mfn)) ) +    { + *ipat = 1; + return MTRR_TYPE_UNCACHABLE; +    } +      if ( !need_iommu(d) && !cache_flush_permitted(d) )      {          *ipat = 1;