From patchwork Thu Jan 26 08:57:22 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: David Woodhouse X-Patchwork-Id: 9538495 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 A5C04601D7 for ; Thu, 26 Jan 2017 09:00:11 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 9403E25E13 for ; Thu, 26 Jan 2017 09:00:11 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 87D4128112; Thu, 26 Jan 2017 09:00:11 +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 A4F5525E13 for ; Thu, 26 Jan 2017 09:00:09 +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 1cWfsB-0001gQ-Qu; Thu, 26 Jan 2017 08:57:39 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cWfsA-0001gK-Kg for xen-devel@lists.xen.org; Thu, 26 Jan 2017 08:57:38 +0000 Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id 1A/74-25657-10AB9885; Thu, 26 Jan 2017 08:57:37 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrAIsWRWlGSWpSXmKPExsUSNTvmoi7Drs4 Ig11bRSyWfFzM4sDocXT3b6YAxijWzLyk/IoE1oy5XQsZC95HVuxrO8DcwPgtpIuRi0NIYAOj xK7pVxi7GDk5eAVMJRYvmM4OYgsLOEmcOX8AzGYT0JY4sOMkC4gtIqAs0fvrN5jNLFAscanxN BOIzSlgL7HpxERmiKETGCU2XmtjhSiqlfh/dSfYAhYBVYnOt6uBGjiAlglK/N0hDBKWENCQeN iyjhHCbmOUuLfabgIj7ywk3bMQOiDCmhKt23+zQ9jaEssWvmaGsG0l9l9dCWWbSrw++pERwla UmNL9kH0BI/sqRvXi1KKy1CJdM72kosz0jJLcxMwcXUMDY73c1OLixPTUnMSkYr3k/NxNjMCQ rWdgYNzBeKXN+RCjJAeTkijvTe3OCCG+pPyUyozE4oz4otKc1OJDjDIcHEoSvO93AOUEi1LTU yvSMnOA0QOTluDgURLhLQdJ8xYXJOYWZ6ZDpE4xKkqJ8x4BSQiAJDJK8+DaYBF7iVFWSpiXkY GBQYinILUoN7MEVf4VozgHo5Iw7yGQKTyZeSVw018BLWYCWnyBuR1kcUkiQkqqgdHuXaTrv2a PCVcijr9bmnlgReS0ycbXd+acMtylc7g/8Aifi/SKLdeq2OMW2mc4aZ4Xf8r+8JUJo9yG39f1 0mdpPVhT1CjH8Npsjuj1ZgE+q/d13HJMXDJW51fN3GATfWP2XPall7MPWP/j8jNrZf0weY+6P 4PZZTPuLZvXZ4QE8//NXTlb/YUSS3FGoqEWc1FxIgDj5K500wIAAA== X-Env-Sender: BATV+b0eccc5b516484db75e9+4904+infradead.org+dwmw2@twosheds .srs.infradead.org X-Msg-Ref: server-6.tower-31.messagelabs.com!1485421056!56109132!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 43877 invoked from network); 26 Jan 2017 08:57:36 -0000 Received: from twosheds.infradead.org (HELO twosheds.infradead.org) (90.155.92.209) by server-6.tower-31.messagelabs.com with AES256-GCM-SHA384 encrypted SMTP; 26 Jan 2017 08:57:36 -0000 Received: from [2001:8b0:10b:1:3cf1:aac7:7113:5830] by twosheds.infradead.org with esmtpsa (Exim 4.87 #1 (Red Hat Linux)) id 1cWfrv-000540-9y; Thu, 26 Jan 2017 08:57:23 +0000 Message-ID: <1485421042.4727.173.camel@infradead.org> From: David Woodhouse To: Jan Beulich In-Reply-To: <5888C2810200007800133CDC@prv-mh.provo.novell.com> References: <1485353329.4727.111.camel@infradead.org> <5888C2810200007800133CDC@prv-mh.provo.novell.com> Date: Thu, 26 Jan 2017 08:57:22 +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] x86: Allow write-combining on 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 Since the fix for XSA-154 in commit c61a6f74f80e ("x86: enforce consistent cachability of MMIO mappings"), HVM guests have no longer been able to use PAT to obtain write-combining on MMIO because the 'ignore PAT' bit is set in EPT. For MMIO we shouldn't be setting the 'ignore PAT' bit, although we probably want to err on the side of caution and still do so for addresses in mmio_ro_ranges. That necessitates a slight refactoring to let the MMIO (for which mfn_vaiid() can be false) 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;