From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39795) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZDHRY-0003d5-Cd for qemu-devel@nongnu.org; Thu, 09 Jul 2015 15:25:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZDHRU-0006ps-Ae for qemu-devel@nongnu.org; Thu, 09 Jul 2015 15:25:12 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51448) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZDHRU-0006on-5x for qemu-devel@nongnu.org; Thu, 09 Jul 2015 15:25:08 -0400 From: Bandan Das References: <20150709145105.1c533e4c@nial.brq.redhat.com> Date: Thu, 09 Jul 2015 15:25:05 -0400 In-Reply-To: <20150709145105.1c533e4c@nial.brq.redhat.com> (Igor Mammedov's message of "Thu, 9 Jul 2015 14:51:05 +0200") Message-ID: MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH] target-i386: Sanity check host processor physical address width List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov Cc: Paolo Bonzini , Laszlo Ersek , qemu-devel@nongnu.org, kvm@vger.kernel.org, Eduardo Habkost Igor Mammedov writes: > On Wed, 08 Jul 2015 18:42:01 -0400 > Bandan Das wrote: > >> >> If a Linux guest is assigned more memory than is supported >> by the host processor, the guest is unable to boot. That >> is expected, however, there's no message indicating the user >> what went wrong. This change prints a message to stderr if >> KVM has the corresponding capability. >> >> Reported-by: Laszlo Ersek >> Signed-off-by: Bandan Das >> --- >> linux-headers/linux/kvm.h | 1 + >> target-i386/kvm.c | 6 ++++++ >> 2 files changed, 7 insertions(+) >> >> diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h >> index 3bac873..6afad49 100644 >> --- a/linux-headers/linux/kvm.h >> +++ b/linux-headers/linux/kvm.h >> @@ -817,6 +817,7 @@ struct kvm_ppc_smmu_info { >> #define KVM_CAP_DISABLE_QUIRKS 116 >> #define KVM_CAP_X86_SMM 117 >> #define KVM_CAP_MULTI_ADDRESS_SPACE 118 >> +#define KVM_CAP_PHY_ADDR_WIDTH 119 >> >> #ifdef KVM_CAP_IRQ_ROUTING >> >> diff --git a/target-i386/kvm.c b/target-i386/kvm.c >> index 066d03d..66e3448 100644 >> --- a/target-i386/kvm.c >> +++ b/target-i386/kvm.c >> @@ -892,6 +892,7 @@ int kvm_arch_init(MachineState *ms, KVMState *s) >> uint64_t shadow_mem; >> int ret; >> struct utsname utsname; >> + int max_phys_bits; >> >> ret = kvm_get_supported_msrs(s); >> if (ret < 0) { >> @@ -945,6 +946,11 @@ int kvm_arch_init(MachineState *ms, KVMState *s) >> } >> } >> >> + max_phys_bits = kvm_check_extension(s, KVM_CAP_PHY_ADDR_WIDTH); > max_phys_bits seems generic enough and could be applied to other targets > as well. I am a little clueless about other targets but is figuring this out from userspace as simple as it's on x86 (cpuid)? If not, then I agree, this could be made a generic value. Bandan > making it a property of machine, would make accessing/manipulating it easier. > define default value for machine/TCG mode and when KVM is enabled > it would override/set its own limit. > > then any board could easily access machine->max_gpa to make board specific > checks. > >> + if (max_phys_bits && (1ULL << max_phys_bits) <= ram_size) >> + fprintf(stderr, "Warning: The amount of memory assigned to the guest " >> + "is more than that supported by the host CPU(s). Guest may be unstable.\n"); >> + >> if (kvm_check_extension(s, KVM_CAP_X86_SMM)) { >> smram_machine_done.notify = register_smram_listener; >> qemu_add_machine_init_done_notifier(&smram_machine_done);