From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [PATCH] target-i386: Sanity check host processor physical address width Date: Thu, 9 Jul 2015 15:04:15 +0200 Message-ID: <559E714F.1080505@redhat.com> References: <559E29C4.6000208@redhat.com> <559E304B.4090706@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, Eduardo Habkost To: Laszlo Ersek , Bandan Das , qemu-devel@nongnu.org Return-path: Received: from mx1.redhat.com ([209.132.183.28]:58973 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753443AbbGINES (ORCPT ); Thu, 9 Jul 2015 09:04:18 -0400 In-Reply-To: <559E304B.4090706@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 09/07/2015 10:26, Laszlo Ersek wrote: >> > >> > 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). The reason I mentioned the firmware is because you could in principle have the same issue on real hardware - say putting 128 GB on your laptop. The firmware should cope with it. If OVMF does not use etc/e820, it can instead hack the values it reads from CMOS, bounding them according to the CPUID value. Paolo