Re: [Qemu-devel] [PATCH] fix guest physical bits to match host, to go beyond 1TB guests

[Paolo Bonzini <pbonzini@redhat.com>]

Il 16/07/2013 21:42, Eduardo Habkost ha scritto:
> On Tue, Jul 16, 2013 at 09:24:30PM +0200, Paolo Bonzini wrote:
>> Il 16/07/2013 20:11, Eduardo Habkost ha scritto:
>>> For physical bit size, what about extending it in a backwards-compatible
>>> way? Something like this:
>>>
>>>     *eax = 0x0003000; /* 48 bits virtual */
>>>     if (ram_size < 1TB) {
>>>         physical_size = 40; /* Keeping backwards compatibility */
>>>     } else if (ram_size < 4TB) {
>>>         physical_size = 42;
>>
>> Why not go straight up to 44?
> 
> I simply trusted the comment saying: "The physical address space is
> limited to 42 bits in exec.c", and assumed we had a 42-bit limit
> somewhere else.

Yeah, that's obsolete.  We now can go up to 64 (but actually only
support 52 because that's what Intel says will be the limit----4PB RAM
should be good for everyone, as Bill Gates used to say).

So far Intel has been upgrading the physical RAM size in x16 steps
(MAXPHYADDR was 36, then 40, then 44).  MAXPHYADDR is how Intel calls
what you wrote as physical_size.

>     if (ram_size < 1TB) {
>         physical_size = 40; /* Keeping backwards compatibility */
>     } else {
>         physical_size = msb(ram_size);
>     }
>     if (supported_host_physical_size() < physical_size) {
>         abort();
>     }

Not enough because there are processors with 36.  So perhaps, putting
together both of your ideas:

     if (supported_host_physical_size() < msb(ram_size)) {
         abort();
     }
     if (ram_size < 64GB && !some_compat_prop) {
         physical_size = 36;
     } else if (ram_size < 1TB) {
         physical_size = 40;
     } else {
         physical_size = 44;
     }

What do you think?

>> This makes sense too.  Though the best would be of course to use CPUID
>> values coming from the real processors, and only using 40 for backwards
>> compatibility.
> 
> We can't use the values coming from the real processors directly, or
> we will break live migration.

I said real processors, not host processors. :)

So a Core 2 has MAXPHYADDR=36, Nehalem has IIRC 40, Sandy Bridge has 44,
and so on.

> If we sent those CPUID bits as part of the migration stream, it would
> make it a little safer, but then it would be impossible for libvirt to
> tell if it is really possible to migrate from one host to another.

The libvirt problem still remains, since libvirt currently doesn't know
the MAXPHYADDRs and would have to learn them.

I guess the above "artificial" computation of MAXPHYADDR is enough.

Paolo