From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35003) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZD7Af-0006ky-9L for qemu-devel@nongnu.org; Thu, 09 Jul 2015 04:27:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZD7Aa-0008PV-66 for qemu-devel@nongnu.org; Thu, 09 Jul 2015 04:27:05 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37695) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZD7AZ-0008PJ-OZ for qemu-devel@nongnu.org; Thu, 09 Jul 2015 04:27:00 -0400 Message-ID: <559E304B.4090706@redhat.com> Date: Thu, 09 Jul 2015 10:26:51 +0200 From: Laszlo Ersek MIME-Version: 1.0 References: <559E29C4.6000208@redhat.com> In-Reply-To: <559E29C4.6000208@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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: Paolo Bonzini , Bandan Das , qemu-devel@nongnu.org Cc: Eduardo Habkost , kvm@vger.kernel.org On 07/09/15 09:59, Paolo Bonzini wrote: > > > On 09/07/2015 00:42, 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 > > This is not entirely correct, because it doesn't take the PCI hole into > account. > > Perhaps KVM could simply hide memory above the limit (i.e. treat it as > MMIO), and the BIOS could remove RAM above the limit from the e820 > memory map? I'd prefer to leave the guest firmware*s* out of this... :) E820 is a legacy BIOS concept. In OVMF we'd have to hack the memory resource descriptor HOBs (which in turn control the DXE memory space map, which in turn controls the UEFI memory map). Those HOBs are currently based on what the CMOS reports about the RAM available under and above 4GB. It's pretty complex already (will get more complex with SMM support), and TBH, for working around such an obscure issue, I wouldn't like to complicate it even further... After all, this is a host platform limitation. The solution should be to either move to a more capable host, or do it in software (disable EPT). Thanks! Laszlo > > Paolo > >> --- >> 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); >> + 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); >>