qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] target-i386: Sanity check host processor physic


From: Bandan Das
Subject: Re: [Qemu-devel] [PATCH] target-i386: Sanity check host processor physical address width
Date: Thu, 09 Jul 2015 15:22:18 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Paolo Bonzini <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]