Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754940AbcKYPLj (ORCPT ); Fri, 25 Nov 2016 10:11:39 -0500 Received: from mx1.redhat.com ([209.132.183.28]:44744 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754627AbcKYPLc (ORCPT ); Fri, 25 Nov 2016 10:11:32 -0500 Subject: Re: [PATCH] KVM: x86: restrict maximal physical address To: =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , linux-kernel@vger.kernel.org, kvm@vger.kernel.org References: <20161125145105.9508-1-rkrcmar@redhat.com> Cc: Paolo Bonzini From: David Hildenbrand Organization: Red Hat GmbH Message-ID: <88fa28cd-6d81-6f88-871c-484973b98292@redhat.com> Date: Fri, 25 Nov 2016 16:11:29 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161125145105.9508-1-rkrcmar@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Fri, 25 Nov 2016 15:11:31 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1559 Lines: 48 Am 25.11.2016 um 15:51 schrieb Radim Krčmář: > The guest could have configured a maximal physical address that exceeds > the host. Prevent that situation as it could easily lead to a bug. > > Signed-off-by: Radim Krčmář > --- > arch/x86/kvm/cpuid.c | 8 +++++++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c > index 25f0f15fab1a..aed910e9fbed 100644 > --- a/arch/x86/kvm/cpuid.c > +++ b/arch/x86/kvm/cpuid.c > @@ -136,7 +136,13 @@ int kvm_update_cpuid(struct kvm_vcpu *vcpu) > ((best->eax & 0xff00) >> 8) != 0) > return -EINVAL; > > - /* Update physical-address width */ > + > + /* > + * Update physical-address width. > + * Make sure that it does not exceed hardware capabilities. > + */ > + if (cpuid_query_maxphyaddr(vcpu) > boot_cpu_data.x86_phys_bits) The name maxphyaddr is really misleading. But that is a different story. This check is correct. However, I wonder if there is any way for user space to query this property? On s390x, there is a kvm capability to export this information to user space. So QEMU can fail (e.g. migration) with a nice error message about missing hardware support. (most probably we still want to block this case, as migration will seem to work but than simply fail due to missing hardware support I guess). Maybe there is also already a nice check in QEMU that I am not yet aware of :) > + return -EINVAL; > vcpu->arch.maxphyaddr = cpuid_query_maxphyaddr(vcpu); > > kvm_pmu_refresh(vcpu); > -- David