From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5933BC43469 for ; Mon, 21 Sep 2020 15:36:13 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E3E0C20888 for ; Mon, 21 Sep 2020 15:36:12 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=citrix.com header.i=@citrix.com header.b="CTj1iXVQ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E3E0C20888 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=citrix.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kKNrF-0005po-6h; Mon, 21 Sep 2020 15:36:01 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kKNrD-0005pi-Lx for xen-devel@lists.xenproject.org; Mon, 21 Sep 2020 15:35:59 +0000 X-Inumbo-ID: 3bad452f-595c-4430-a279-4a7a117fc6be Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 3bad452f-595c-4430-a279-4a7a117fc6be; Mon, 21 Sep 2020 15:35:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=citrix.com; s=securemail; t=1600702555; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=3wMcflPgctskZ+axprx0uNI+7BPpV60RCOCNgtnGUQM=; b=CTj1iXVQ38VVK+MInILVHByRj8Yc7IORAoNwQ9E9YC867HbntaSeT3QX z9VJFdMaephBTVJo75qwH/9j9M4ZiQ5Gy/MgERcVXbuGBYO2vbh09nNId NOQAz8aA8HaB1FjjckxhsRdDIs2qCRsKpOSFlGbz7k7W5sLKssjxwGn07 c=; Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: PjDxfgdOqiiwW/W5/ilTahMUC++PYG1jumO3UAxMgymF9Zph+74t1/gx9MUweu2zrJg69Zs3ud GIdOwY33NPEUM7vaU/tqirarXE76UhUThyW4ZLPCQaY2svtiFnhHD4WDPuiCVhAzHwq9ivFwKL v03FvoWLcGWMWTeBcYufCo/mTgbjRMK5PZLjrSARPCuxyVcYbI9IqEsR+MaC4v8YphrDj8YH34 oG2+KGWSivGB0iZCC1oCfunFQhBl5NV6F317KaIYtNRsWWRYdkL5jttgAdxwJfThuOgY+z/02R 5w8= X-SBRS: 2.7 X-MesageID: 27148439 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.77,286,1596513600"; d="scan'208";a="27148439" Date: Mon, 21 Sep 2020 17:35:45 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich CC: , Andrew Cooper , Wei Liu , Paul Durrant Subject: Re: [PATCH] x86/mm: do not mark IO regions as Xen heap Message-ID: <20200921153545.GG19254@Air-de-Roger> References: <20200910133514.82155-1-roger.pau@citrix.com> <3b61c04e-b2ef-a9c6-c3c4-e1d8624e7115@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: <3b61c04e-b2ef-a9c6-c3c4-e1d8624e7115@suse.com> X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To FTLPEX02CL06.citrite.net (10.13.108.179) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, Sep 21, 2020 at 04:22:26PM +0200, Jan Beulich wrote: > On 10.09.2020 15:35, Roger Pau Monne wrote: > > arch_init_memory will treat all the gaps on the physical memory map > > between RAM regions as MMIO and use share_xen_page_with_guest in order > > to assign them to dom_io. This has the side effect of setting the Xen > > heap flag on such pages, and thus is_special_page would then return > > true which is an issue in epte_get_entry_emt because such pages will > > be forced to use write-back cache attributes. > > > > Fix this by introducing a new helper to assign the MMIO regions to > > dom_io without setting the Xen heap flag on the pages, so that > > is_special_page will return false and the pages won't be forced to use > > write-back cache attributes. > > > > Fixes: 81fd0d3ca4b2cd ('x86/hvm: simplify 'mmio_direct' check in epte_get_entry_emt()') > > Is this really the correct commit? I had this queued for backport, > and ended up discarding it from the queue based on this tag, just > to then noticing that I remembered correctly that I did backport > ca24b2ffdbd9 ("x86/hvm: set 'ipat' in EPT for special pages") to > the stable trees already. Isn't it _this_ commit which the change > here fixes? My bisection pointed to that exact commit as the one that broke my PVH dom0 setup, so yes, I'm quite sure that's the commit at least on the box that I've bisected it. ca24b2ffdbd9 was still fine because previous to the is_special_page check loop there was still the `if ( direct_mmio ) ...` handling, which made all MMIO regions except for the APIC access page forcefully have it's cache attributes set to UC. Roger.