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

[Eduardo Habkost]

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.

We could also try something like this:

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


> 
> >     } else {
> >         abort();
> >     }
> >     if (supported_host_physical_size() < physical_size) {
> >         abort();
> >     }
> >     *eax |= physical_size;
> > 
> > (Of course, the abort() calls should be replaced with proper error
> > reporting)
> 
> 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.

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.

In other words, if QEMU silently decide to expose a different ABI
depending on host capabilities, we have to either: a) silently break the
ABI when migrating to an incompatible host; b) prevent migration to an
incompatible host, but make it impossible for the management layer to
know if migration is really possible.

(The above applies to CPUID leaves 0xA and 0xD as well)

-- 
Eduardo