[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] target-i386: Sanity check host processor physic
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [PATCH] target-i386: Sanity check host processor physical address width |
Date: |
Thu, 9 Jul 2015 15:04:15 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 |
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
Re: [Qemu-devel] [PATCH] target-i386: Sanity check host processor physical address width, Paolo Bonzini, 2015/07/09
Re: [Qemu-devel] [PATCH] target-i386: Sanity check host processor physical address width, Igor Mammedov, 2015/07/09