From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39106) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZDHOr-0002Fi-19 for qemu-devel@nongnu.org; Thu, 09 Jul 2015 15:22:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZDHOm-0005Lp-VI for qemu-devel@nongnu.org; Thu, 09 Jul 2015 15:22:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50459) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZDHOm-0005Lj-QD for qemu-devel@nongnu.org; Thu, 09 Jul 2015 15:22:20 -0400 From: Bandan Das References: <559E29C4.6000208@redhat.com> <559E304B.4090706@redhat.com> <559E714F.1080505@redhat.com> Date: Thu, 09 Jul 2015 15:22:18 -0400 In-Reply-To: <559E714F.1080505@redhat.com> (Paolo Bonzini's message of "Thu, 9 Jul 2015 15:04:15 +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: Paolo Bonzini Cc: Laszlo Ersek , qemu-devel@nongnu.org, kvm@vger.kernel.org, Eduardo Habkost Paolo Bonzini writes: > 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. Agreed, it's probably not a good idea to deviate too much from how real hardware would behave IMO. As a simplification of Paolo's idea, is it possible for qemu to completely ignore memory above the limit ? Will that break anything ? :) > 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