From nobody Fri Nov 7 09:11:04 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail(p=none dis=none) header.from=redhat.com Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1547478418214924.7456557850751; Mon, 14 Jan 2019 07:06:58 -0800 (PST) Received: from localhost ([127.0.0.1]:48581 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gj3pI-0002Fk-LN for importer@patchew.org; Mon, 14 Jan 2019 10:06:56 -0500 Received: from eggs.gnu.org ([209.51.188.92]:57004) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gj3KK-0000iW-Vc for qemu-devel@nongnu.org; Mon, 14 Jan 2019 09:34:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gj3KI-0005jc-W3 for qemu-devel@nongnu.org; Mon, 14 Jan 2019 09:34:56 -0500 Received: from mx1.redhat.com ([209.132.183.28]:8843) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gj3KH-0005hE-2z for qemu-devel@nongnu.org; Mon, 14 Jan 2019 09:34:54 -0500 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9D65E88E48; Mon, 14 Jan 2019 14:34:50 +0000 (UTC) Received: from localhost (ovpn-116-76.gru2.redhat.com [10.97.116.76]) by smtp.corp.redhat.com (Postfix) with ESMTP id 209C15D759; Mon, 14 Jan 2019 14:34:49 +0000 (UTC) From: Eduardo Habkost To: Peter Maydell , qemu-devel@nongnu.org Date: Mon, 14 Jan 2019 12:34:31 -0200 Message-Id: <20190114143432.4771-5-ehabkost@redhat.com> In-Reply-To: <20190114143432.4771-1-ehabkost@redhat.com> References: <20190114143432.4771-1-ehabkost@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Mon, 14 Jan 2019 14:34:50 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PULL 4/5] x86: host-phys-bits-limit option X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Eduardo Habkost , kvm@vger.kernel.org, "Michael S. Tsirkin" , Marcelo Tosatti , Paolo Bonzini , Richard Henderson Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Some downstream distributions of QEMU set host-phys-bits=3Don by default. This worked very well for most use cases, because phys-bits really didn't have huge consequences. The only difference was on the CPUID data seen by guests, and on the handling of reserved bits. This changed in KVM commit 855feb673640 ("KVM: MMU: Add 5 level EPT & Shadow page table support"). Now choosing a large phys-bits value for a VM has bigger impact: it will make KVM use 5-level EPT even when it's not really necessary. This means using the host phys-bits value may not be the best choice. Management software could address this problem by manually configuring phys-bits depending on the size of the VM and the amount of MMIO address space required for hotplug. But this is not trivial to implement. However, there's another workaround that would work for most cases: keep using the host phys-bits value, but only if it's smaller than 48. This patch makes this possible by introducing a new "-cpu" option: "host-phys-bits-limit". Management software or users can make sure they will always use 4-level EPT using: "host-phys-bits=3Don,host-phys-bits-limit=3D48". This behavior is still not enabled by default because QEMU doesn't enable host-phys-bits=3Don by default. But users, management software, or downstream distributions may choose to change their defaults using the new option. Signed-off-by: Eduardo Habkost Message-Id: <20181211192527.13254-1-ehabkost@redhat.com> [ehabkost: removed test code while some issues are addressed] Signed-off-by: Eduardo Habkost --- target/i386/cpu.h | 3 +++ target/i386/cpu.c | 5 +++++ 2 files changed, 8 insertions(+) diff --git a/target/i386/cpu.h b/target/i386/cpu.h index 386094a241..59656a70e6 100644 --- a/target/i386/cpu.h +++ b/target/i386/cpu.h @@ -1461,6 +1461,9 @@ struct X86CPU { /* if true override the phys_bits value with a value read from the hos= t */ bool host_phys_bits; =20 + /* if set, limit maximum value for phys_bits when host_phys_bits is tr= ue */ + uint8_t host_phys_bits_limit; + /* Stop SMI delivery for migration compatibility with old machines */ bool kvm_no_smi_migration; =20 diff --git a/target/i386/cpu.c b/target/i386/cpu.c index 9d4dccf020..3ece83696e 100644 --- a/target/i386/cpu.c +++ b/target/i386/cpu.c @@ -5178,6 +5178,10 @@ static void x86_cpu_realizefn(DeviceState *dev, Erro= r **errp) if (cpu->host_phys_bits) { /* The user asked for us to use the host physical bits */ cpu->phys_bits =3D host_phys_bits; + if (cpu->host_phys_bits_limit && + cpu->phys_bits > cpu->host_phys_bits_limit) { + cpu->phys_bits =3D cpu->host_phys_bits_limit; + } } =20 /* Print a warning if the user set it to a value that's not the @@ -5765,6 +5769,7 @@ static Property x86_cpu_properties[] =3D { DEFINE_PROP_BOOL("kvm", X86CPU, expose_kvm, true), DEFINE_PROP_UINT32("phys-bits", X86CPU, phys_bits, 0), DEFINE_PROP_BOOL("host-phys-bits", X86CPU, host_phys_bits, false), + DEFINE_PROP_UINT8("host-phys-bits-limit", X86CPU, host_phys_bits_limit= , 0), DEFINE_PROP_BOOL("fill-mtrr-mask", X86CPU, fill_mtrr_mask, true), DEFINE_PROP_UINT32("level", X86CPU, env.cpuid_level, UINT32_MAX), DEFINE_PROP_UINT32("xlevel", X86CPU, env.cpuid_xlevel, UINT32_MAX), --=20 2.18.0.rc1.1.g3f1ff2140