Hi, > What I overlooked was the emphasis you had on desktops (qemu default bigger > than > host-advertised), where I am thinking mostly in servers.
Yep, on servers you have the reverse problem that phys-bits=40 might be too small for very large guests. > > 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. > > > Your 2 paragraphs sound like it's two different things, but +host-phys-bits > just sets CPUID.80000008.EAX with the host CPUID equivalent leaf/register > value. Which yes, it makes it reliable, but the way to convey is still the > same. That is regardless, of phys-bits=bogus-bigger-than-host-number, > host-phys-bits=on or host-phys-bits-limit=N. Yep, it's CPUID.80000008.EAX in all cases. > > 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. > > What I am not enterily sure from (1) is the value on having a 'guest > phys-bits' > and a 'host phys-bits' *exposed to the guest* when it seems we are picking > the wrong > value for guests. Well, the guest can read CPUID.80000008.EAX but as of today the guest just doesn't know whenever it's bogus or not. > It seems unnecessary redirection (compared to real hw) unless > there's a use-case in keeping both that I am probably missing. Well, the use case is backward compatibility. If we want make better use of the guest physical address space on newer qemu without breaking compatibility with older qemu versions the firmware needs to do something along the lines of: if (i-can-trust-phys-bits) { // new qemu read CPUID.80000008.EAX and go with that } else { // old qemu use current heuristic, placing stuff as low as possible. } And for that to actually work new qemu needs to expose something to the guest which can be used to evaluate the "i-can-trust-phys-bits" expression. A guest-readable bit somewhere which is 1 for host-phys-bits=on and 0 otherwise would do the trick, but there are surely other ways to solve the problem. take care, Gerd