Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp3156646ybt; Mon, 22 Jun 2020 16:52:56 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyhoM4Nxf9l789711fg0+8AspfomBUUkpxcK1netJuTSa1fz09ap6FMFxf1etCf3mBKVfWT X-Received: by 2002:a17:907:216c:: with SMTP id rl12mr18824431ejb.156.1592869975851; Mon, 22 Jun 2020 16:52:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592869975; cv=none; d=google.com; s=arc-20160816; b=I/x1D9nqS3Suv63BFynqEjpqSG1hU62TloYcwHQdSHdFSLYA1xL2PAR5rG0IwaRTSR 0p1VyXc5++hmCNBnkcmh2WOrjowqFEOnPubVRAsmHl2g/w2fceS4K9hohlh4l4nisMXO GZPdu8OPKjNhZD8Ml7voFAzmCKkHQVgu2BwzAKir569xZ6jtrXXQWAbQgxZ+kjD0WrG8 KQb6i/Iwq9GnCd2DtO7mKIhd3LFA6OOBmSqMw5wRcEA1f01uCyrI3vxZHX1hpUsbMXsY s4vUjJNxn7UuhlnwUrzpo13117O4SZFBlFtsz2ieo0Lef7O2R9Os0wrKF7qtKvZjpl4h 4GtA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=JTvITH8zv2UiirsD4c1fgFQNvQdvFMxIvcN0BCe53iI=; b=F0yClwgWd8bUIciicwy38rKirdfnlgSMcRcpfSSkxsINHmv02qx3hMtcstqusDbJBW nsO2+QCWPvcim7U7VYejJdxnVWCWM/80MHCRKPTEo77oqMarg3L4qyxbwJ+JH4En4mTX 6iRDFdYgk5nD1M6LrGbczyrIvR+nePnVwp1h8zJB0YFdN8CxRVy8z+c4bkyJmVFxN1WP 8YEItxiNssFQ4EDwvwPAT5VPdtvpzKZSVUnsVEreBDcKBfWJv59NKQucLMzDa1f7NDTs ZYADwpKP7fR5YwQksWON3GGUVpxuW+qnp9tWH+SGZGk89I4dbJ4D9lPEve4k4ceX7kcH W1ug== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u7si9914438ejr.69.2020.06.22.16.52.33; Mon, 22 Jun 2020 16:52:55 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730544AbgFVXrg (ORCPT + 99 others); Mon, 22 Jun 2020 19:47:36 -0400 Received: from mail-pl1-f193.google.com ([209.85.214.193]:46697 "EHLO mail-pl1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731112AbgFVXre (ORCPT ); Mon, 22 Jun 2020 19:47:34 -0400 Received: by mail-pl1-f193.google.com with SMTP id n2so8283031pld.13 for ; Mon, 22 Jun 2020 16:47:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=JTvITH8zv2UiirsD4c1fgFQNvQdvFMxIvcN0BCe53iI=; b=etokx5WlVlTFgmUrw5dhPu8rM2K4Wy3oMC1e3d7mt89IxscoWmX1V5gbTxujt9z+bR k4tfyLQSpaThdzwJnGaKSXJLX9I3I7i81eWBIl6FlHh4GDLQfY1xHv6rg8jSnbgE0FBv BuRv1mqteRqCEzpWfR9NvWMfAIG4SpG378ml/xpkGHJFP375TroMl5dQjqyMzEXtkIXx WCop+dtrDraYTy8sWvJ3ZiEEsLF43sQfNndDqh3HjqvQc71+M3kh2KVXfPyqMDkneorf BQwiUj3pZRCKWQOLke00JrbOLDRgBP/4Tk/j7zcrSITmBboCVwAMhlwsJfQhB0ofe3Lm BN0g== X-Gm-Message-State: AOAM5332USLgQlojlii/xnf/yBGT/fOIrjGT6iiCLU+g9XlIHVGpHMc9 iZXpR3gAouyPgJsaYmFWjnXv0Q== X-Received: by 2002:a17:902:ee12:: with SMTP id z18mr21870343plb.211.1592869653523; Mon, 22 Jun 2020 16:47:33 -0700 (PDT) Received: from ?IPv6:2601:646:c200:1ef2:3602:86ff:fef6:e86b? ([2601:646:c200:1ef2:3602:86ff:fef6:e86b]) by smtp.googlemail.com with ESMTPSA id n189sm15178382pfn.108.2020.06.22.16.47.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 22 Jun 2020 16:47:32 -0700 (PDT) Subject: Re: [PATCH v2 00/11] KVM: Support guest MAXPHYADDR < host MAXPHYADDR To: Paolo Bonzini , Tom Lendacky , Mohammed Gamal , kvm@vger.kernel.org Cc: linux-kernel@vger.kernel.org, vkuznets@redhat.com, sean.j.christopherson@intel.com, wanpengli@tencent.com, jmattson@google.com, joro@8bytes.org, babu.moger@amd.com References: <20200619153925.79106-1-mgamal@redhat.com> <5a52fd65-e1b2-ca87-e923-1d5ac167cfb9@amd.com> <52295811-f78a-46c5-ff9e-23709ba95a3d@redhat.com> From: Andy Lutomirski Message-ID: <2bcdb1cb-c0c5-5447-eed5-6fb094ae7f19@kernel.org> Date: Mon, 22 Jun 2020 16:47:31 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <52295811-f78a-46c5-ff9e-23709ba95a3d@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 6/19/20 4:07 PM, Paolo Bonzini wrote: > On 19/06/20 23:52, Tom Lendacky wrote: >>> A more subtle issue is when the host MAXPHYADDR is larger than that >>> of the guest. Page faults caused by reserved bits on the guest won't >>> cause an EPT violation/NPF and hence we also check guest MAXPHYADDR >>> and add PFERR_RSVD_MASK error code to the page fault if needed. >> >> I'm probably missing something here, but I'm confused by this >> statement. Is this for a case where a page has been marked not >> present and the guest has also set what it believes are reserved >> bits? Then when the page is accessed, the guest sees a page fault >> without the error code for reserved bits? > > No, for non-present page there is no issue because there are no reserved > bits in that case. If the page is present and no reserved bits are set > according to the host, however, there are two cases to consider: > > - if the page is not accessible to the guest according to the > permissions in the page table, it will cause a #PF. We need to trap it > and change the error code into P|RSVD if the guest physical address has > any guest-reserved bits. You say "we need to trap it". I think this should have a clear justification for exactly what this accomplishes and how it benefits what real-world guests. The performance implications and the exact condition under which they apply should IMO be clearly documented in Documentation/, in the code, or, at the very least, in the changelog. I don't see such docs right now. As I understand it, the problematic case is where a guest OS intentionally creates a present PTE with reserved bits set. (I believe that Xen does this. Linux does not.) For a guest to actually be functional in this case, the guest needs to make sure that it is not setting bits that are not, in fact, reserved on the CPU. This means the guest needs to check MAXPHYADDR and do something different on different CPUs. Do such guests exist? As far as I know, Xen is busted on systems with unusually large MAXPHYADDR regardless of any virtualization issues, so, at best, this series would make Xen, running as a KVM guest, work better on new hardware than it does running bare metal on that hardware. This seems like an insufficient justification for a performance-eating series like this. And, unless I've misunderstood, this will eat performance quite badly. Linux guests [0] (and probably many other guests), in quite a few workloads, is fairly sensitive to the performance of ordinary write-protect or not-present faults. Promoting these to VM exits because you want to check for bits above the guest's MAXPHYADDR is going to hurt. (Also, I'm confused. Wouldn't faults like this be EPT/NPT violations, not page faults?) --Andy [0] From rather out-of-date memory, Linux doesn't make as much use as one might expect of the A bit. Instead it uses minor faults. Ouch.