From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:42776)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <ehabkost@redhat.com>) id 1Uz9D7-0005u0-6i
	for qemu-devel@nongnu.org; Tue, 16 Jul 2013 13:38:50 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <ehabkost@redhat.com>) id 1Uz9D5-0007cp-DF
	for qemu-devel@nongnu.org; Tue, 16 Jul 2013 13:38:49 -0400
Date: Tue, 16 Jul 2013 14:38:44 -0300
From: Eduardo Habkost <ehabkost@redhat.com>
Message-ID: <20130716173844.GC19826@otherpad.lan.raisama.net>
References: <1373995321-2470-1-git-send-email-aarcange@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1373995321-2470-1-git-send-email-aarcange@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] fix guest physical bits to match host,
 to go beyond 1TB guests
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Andrea Arcangeli <aarcange@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, qemu-devel@nongnu.org, Gleb Natapov <gleb@redhat.com>, qemu-stable@nongnu.org

On Tue, Jul 16, 2013 at 07:22:01PM +0200, Andrea Arcangeli wrote:
> 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)

I am not sure I understand what caused this: if we are advertising 40
physical bits to the guest, why are we ending up with a 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);
> +            }

We can't expose a different virtual machine depending on host
capabilities. What if we live-migrate between hosts with different
physical address bit sizes?

>          } else {
>              if (env->features[FEAT_1_EDX] & CPUID_PSE36) {
>                  *eax = 0x00000024; /* 36 bits physical */
> 

-- 
Eduardo