On Tue, Feb 15, 2022 at 07:37:40PM +0000, Joao Martins wrote:
> On 2/15/22 09:53, Gerd Hoffmann wrote:
> > What is missing:
> >
> > * Some way for the firmware to get a phys-bits value it can actually
> > use. One possible way would be to have a paravirtual bit somewhere
> > telling whenever host-phys-bits is enabled or not.
> >
> If we are not talking about *very old* processors... isn't what already
> advertised in CPUID.80000008 EAX enough? That's the maxphysaddr width
> on x86, which on qemu we do set it with the phys-bits value;
Sigh. Nope. Did you read the complete reply?
Problem is this is not reliable. With host-phys-bits=off (default) qemu
allows to set phys-bits to whatever value you want, including values
larger than what the host actually supports. Which renders
CPUID.80000008.EAX unusable. To make things even worse: The default
value (phys-bits=40) is larger than what many intel boxes support.
host-phys-bits=on fixes that. It makes guest-phys-bits == host-phys-bits
by default, and also enforces guest-phys-bits <= host-phys-bits.
So with host-phys-bits=on the guest can actually use CPUID.80000008.EAX
to figure how big the guest physical address space is.
Problem is the guest doesn't know whenever host-phys-bits is enabled or
not ...
So the options to fix that are:
(1) Make the host-phys-bits option visible to the guest (as suggested
above), or
(2) Advertise a _reliable_ phys-bits value to the guest somehow.
take care,
Gerd
