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 19:22, Andrea Arcangeli ha scritto:
> Without this patch the guest physical bits are advertised as 40, not
> 44 or more depending on the hardware capability of the host.
> 
> That leads to guest kernel crashes with injection of page faults 9
> (see oops: 0009) as bits above 40 in the guest pagetables are
> considered reserved.
> 
> exregion-0206 [324572448] [17] ex_system_memory_space: System-Memory (width 32) R/W 0 Address=00000000FED00000
> BUG: unable to handle kernel paging request at ffffc9006030e000
> IP: [<ffffffff812fbb6f>] acpi_ex_system_memory_space_handler+0x23e/0x2cb
> PGD e01f875067 PUD 1001f075067 PMD e0178d8067 PTE 80000000fed00173
> Oops: 0009 [#1] SMP
> 
> (see PUD with bit >=40 set)
> 
> Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
> Reported-by: Chegu Vinod <chegu_vinod@hp.com>
> ---
>  target-i386/cpu.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/target-i386/cpu.c b/target-i386/cpu.c
> index e3f75a8..0e65673 100644
> --- a/target-i386/cpu.c
> +++ b/target-i386/cpu.c
> @@ -2108,6 +2108,12 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count,
>              /* 64 bit processor */
>  /* XXX: The physical address space is limited to 42 bits in exec.c. */
>              *eax = 0x00003028; /* 48 bits virtual, 40 bits physical */
> +            if (kvm_enabled()) {
> +                uint32_t _eax;
> +                host_cpuid(0x80000000, 0, &_eax, NULL, NULL, NULL);
> +                if (_eax >= 0x80000008)
> +                    host_cpuid(0x80000008, 0, eax, NULL, NULL, NULL);
> +            }
>          } else {
>              if (env->features[FEAT_1_EDX] & CPUID_PSE36) {
>                  *eax = 0x00000024; /* 36 bits physical */
> 

This is fine by me.

It has the usual problem that "-cpu" does not affect most CPUID leaves
(and read-only MSRs too). We have the same problem for vPMU and I think
for leaf 0xD too.  I don't think this should block the patch, though,
it's just one more thing waiting for CPUID infrastructure work.

Let's see what Eduardo thinks.  If he acks the patch, I'll take this
into uq/master.

Paolo