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=-7.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 E63F0C433DB for ; Thu, 25 Feb 2021 13:30:18 +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 6EE6D64DDC for ; Thu, 25 Feb 2021 13:30:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6EE6D64DDC Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.89772.169383 (Exim 4.92) (envelope-from ) id 1lFGiW-0002v2-HG; Thu, 25 Feb 2021 13:30:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 89772.169383; Thu, 25 Feb 2021 13:30:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lFGiW-0002uv-EG; Thu, 25 Feb 2021 13:30:08 +0000 Received: by outflank-mailman (input) for mailman id 89772; Thu, 25 Feb 2021 13:30:06 +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 1lFGiU-0002r0-Rv for xen-devel@lists.xenproject.org; Thu, 25 Feb 2021 13:30:06 +0000 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 218ba7c9-98c4-4338-8d7d-a02680e17ccb; Thu, 25 Feb 2021 13:30:06 +0000 (UTC) Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 7349CAFE5; Thu, 25 Feb 2021 13:30:05 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 218ba7c9-98c4-4338-8d7d-a02680e17ccb X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1614259805; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=FX88hhTm8JfiZk5Vqt5V+3Je8GJxn5GAdxqDaUUwqbo=; b=kahfCopJ8sBjEoty2zW8i6F8rbBQsf2+GS87QbFcSrDjlgAneQZoy1z87sKS8MQ6aUZUwE O0wTb5FRmmOBXGwO/jmjDPxew2F0QAVEMmCIAsyiMEKycfuWtFDEPDHgXkXmsF8Fppuwb2 CeBN5izX9puxys+GBFioGaklk8cqPKg= Subject: Re: [PATCH][4.15] x86/shadow: suppress "fast fault path" optimization without reserved bits To: Ian Jackson Cc: "xen-devel@lists.xenproject.org" , Tim Deegan , George Dunlap , Andrew Cooper , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= References: <24631.41819.456811.665249@mariner.uk.xensource.com> From: Jan Beulich Message-ID: <1226b860-9027-f0e8-6f90-78ec2b57ca7f@suse.com> Date: Thu, 25 Feb 2021 14:30:05 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <24631.41819.456811.665249@mariner.uk.xensource.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 25.02.2021 14:17, Ian Jackson wrote: > Jan Beulich writes ("[PATCH][4.15] x86/shadow: suppress "fast fault path" optimization without reserved bits"): >> When none of the physical address bits in PTEs are reserved, we can't >> create any 4k (leaf) PTEs which would trigger reserved bit faults. Hence >> the present SHOPT_FAST_FAULT_PATH machinery needs to be suppressed in >> this case, which is most easily achieved by never creating any magic >> entries. >> >> To compensate a little, eliminate sh_write_p2m_entry_post()'s impact on >> such hardware. >> >> While at it, also avoid using an MMIO magic entry when that would >> truncate the incoming GFN. > > Judging by the description I'm not sure whether this is a bugfix, or > a change to make it possible to run Xen on hardware where currently it > doesn't work at all. It's still a bug fix imo, even if the flawed assumption was harmless so far. > I assume "none of the physical address bits in PTEs are reserved" is > a property of certain hardware, but it wasn't clear to me (i) whether > such platforms currently exists If they don't exist yet, they're soon to become available afaict. > (ii) what the existing Xen code would do in this case. If memory is populated at the top 4Gb of physical address space, guests would gain access to that memory through these page table entries, as those don't cause the expected faults to be raised anymore (but instead get used for valid - from the hardware's perspective - translations). Jan