Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp3190473ybt; Mon, 22 Jun 2020 17:55:37 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxebEt1fvf0CIa/xwWHLrOMcEuh7+J/V1HBxbTTBaxVXZfXieK3EpHtIAGCFF2wRjxUMc1I X-Received: by 2002:a50:b065:: with SMTP id i92mr20756876edd.112.1592873737050; Mon, 22 Jun 2020 17:55:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592873737; cv=none; d=google.com; s=arc-20160816; b=RMTPnmyb7SM4qmS0Q9+anj9lRWJv2E3dnmJHbV6GSvvIs+6TWynymcx4262j7G7/J1 J12BknlXSgHR9zt1huIW3pkTByrkntrFRkGlZuUQ0zS4OGzUVyFGfW1+nAINAkkMXPGs hSLp++OMkqsh1kONYaZEuLICirNAr0RNzLqbe7PLQ+GRwMMZUEFl7BTdDVHY0qOH8cwl nOfcNXbmURnkFk9p4TDzHBbKrauwuLM0OsnYIbXaNqbYCicA9FP8yf0qRGl4nym5Hw/P HyEOBYjWz3bwwFvf5MG+QuppDRJ40cM94FUxTjoOYI3RFwkRB7M9UEv9LSALAIyrKHh4 yHbA== 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:dkim-signature; bh=Qp7Q2GIXEixRBimL7E9VvblHlm9CvwZes19fF7Y/7hI=; b=FLb819V8NW1EBpjxvhQkUjFRwbbBdJja09Ru5H6MtbT14tXsNV+hx368lQUGd50ZVT wE0duRZBSejR5KxxoO1CtW0bIviJznFLTDeHUl2ohOSSTPKm2ZSEMLcKTc0Q3KlrOHLj hy68f5agJCx2jM7zWZVbYtGnKGyXU4TDljLY5z3a9Hqus7Z1PZeTFNFCAwcSaWajaK9Z /wy4LsDHKNcvsGKLkW8bY9nRR47CYCMxr8OObRL2b8qoKCiEg9qVCQGumC24VhWzlvc3 qNTNYslAXSiJgNIkNgF/X74rNYdJOXZtIttWEX87hqC0u78eMAaTRpAEpIRv4LZ8eZMH cV+g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="ZvA8Z/nR"; 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=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s23si10777298edx.34.2020.06.22.17.55.15; Mon, 22 Jun 2020 17:55:37 -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; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="ZvA8Z/nR"; 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=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732466AbgFWAxG (ORCPT + 99 others); Mon, 22 Jun 2020 20:53:06 -0400 Received: from us-smtp-1.mimecast.com ([207.211.31.81]:21159 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1732460AbgFWAxE (ORCPT ); Mon, 22 Jun 2020 20:53:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1592873583; h=from:from:reply-to:subject:subject: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=Qp7Q2GIXEixRBimL7E9VvblHlm9CvwZes19fF7Y/7hI=; b=ZvA8Z/nRhRUQID1oEGpXmEllUe5w753/EAc1HLdUbtfjdE1BPwG5bjAx6nW/iN1WUtCA/d N73Pcucr8SdDAlSckgbRSmuN+DybrwVTD0mPrV86Nvlaw6ZgBhANgA/CO0XIE1wRlotJUy jQKyCFiRnvmd5C3ipB4sF/I2y654XHI= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-507-D3OtTsFcNmm55oVsX2L50A-1; Mon, 22 Jun 2020 20:53:01 -0400 X-MC-Unique: D3OtTsFcNmm55oVsX2L50A-1 Received: by mail-wm1-f70.google.com with SMTP id t18so1586600wmj.5 for ; Mon, 22 Jun 2020 17:53:01 -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=Qp7Q2GIXEixRBimL7E9VvblHlm9CvwZes19fF7Y/7hI=; b=fL0sEPuaT3xsKVAGi0E+fX7HFfqV9JNlOFtq/7LSAkGw4zVgyOqYcQdSg9qj5a/FrM 5mQKj1ImbPqJbKQIyO0zzec6zTnSNJ1WUELVoDARe0TPLeKzx2yGQeuwo5l3ISgx1k3G CVfAQ5oJ0Z5D1wFKTBMn7wHFL/1IbStjLx9MUL2uBGcufPdsRKmexnBc99utxSjfa2ZU RXoCk5HcdmYgGBcBzq4dafXbJ4s2sFmNtnl1T8h3zIEeTrnCvi91rJtmDu+aZXMzsUxV Kg1MoYCGtojEPgVQY7exH72jaPaA6B8uRpnRt4I6xiA01jWzDItv4wpGuIYuPwdptwDl gRZA== X-Gm-Message-State: AOAM533YjVRWlDpELiqeupOA4KiJonn+GvjGA9bzIFqSAfoKf8Zfo3s5 Gf79FewFIBEHQhzGYevEGBbjcYPvAKy0Pm7C/D2rCphvDBzlLi2XLpJqp76JWXmPGRnFcvJbUvr +Hn0FBM99o6eCOGBlfH+nHQPk X-Received: by 2002:a05:6000:10c4:: with SMTP id b4mr9573846wrx.50.1592873580742; Mon, 22 Jun 2020 17:53:00 -0700 (PDT) X-Received: by 2002:a05:6000:10c4:: with SMTP id b4mr9573825wrx.50.1592873580515; Mon, 22 Jun 2020 17:53:00 -0700 (PDT) Received: from [192.168.10.150] ([93.56.170.5]) by smtp.gmail.com with ESMTPSA id d13sm6038408wrn.61.2020.06.22.17.52.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 22 Jun 2020 17:52:59 -0700 (PDT) Subject: Re: [PATCH v2 00/11] KVM: Support guest MAXPHYADDR < host MAXPHYADDR To: Andy Lutomirski , 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> <2bcdb1cb-c0c5-5447-eed5-6fb094ae7f19@kernel.org> From: Paolo Bonzini Message-ID: Date: Tue, 23 Jun 2020 02:52:58 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <2bcdb1cb-c0c5-5447-eed5-6fb094ae7f19@kernel.org> 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 23/06/20 01:47, Andy Lutomirski wrote: > 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? I don't know; at least KVM does it too when EPT is disabled, though. It tries to minimize the effect of this issue by preferring bit 51, but this does not help if the host MAXPHYADDR is 52. > 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. The series needs benchmarking indeed, however note that the vmexits do not occur for not-present faults. QEMU sets a fixed MAXPHYADDR of 40 but that is generally a bad idea and several distros change that to just use host MAXPHYADDR instead (which would disable the new code). > (Also, I'm confused. Wouldn't faults like this be EPT/NPT > violations, not page faults?) Only if the pages are actually accessible. Otherwise, W/U/F faults would prevail over the RSVD fault. Tom is saying that there's no architectural promise that RSVD faults prevail, either, so that would remove the need to trap #PF. Paolo > --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.