qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>,
	qemu-devel@nongnu.org, Gleb Natapov <gleb@redhat.com>,
	qemu-stable@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] fix guest physical bits to match host, to go beyond 1TB guests
Date: Tue, 16 Jul 2013 19:46:14 +0200	[thread overview]
Message-ID: <51E586E6.1060001@redhat.com> (raw)
In-Reply-To: <20130716173844.GC19826@otherpad.lan.raisama.net>

Il 16/07/2013 19:38, Eduardo Habkost ha scritto:
> 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?

Because we create a guest that has bigger memory than what we advertise
in CPUID.

>>
>> 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?

Same as for vPMU or leaf 0xD: who knows.  In practice, this has an
effect only for guests with 1T or more memory, otherwise the physical
memory is smaller than 40 bits.

Paolo

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

  reply	other threads:[~2013-07-16 17:46 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-16 17:22 [Qemu-devel] [PATCH] fix guest physical bits to match host, to go beyond 1TB guests Andrea Arcangeli
2013-07-16 17:26 ` Paolo Bonzini
2013-07-16 17:38 ` Eduardo Habkost
2013-07-16 17:46   ` Paolo Bonzini [this message]
2013-07-16 17:48     ` Paolo Bonzini
2013-07-16 18:06       ` Andrea Arcangeli
2013-07-16 18:11     ` Eduardo Habkost
2013-07-16 19:24       ` Paolo Bonzini
2013-07-16 19:42         ` Eduardo Habkost
2013-07-17  8:09           ` Paolo Bonzini
2013-07-17 13:39             ` Eduardo Habkost
2013-07-17 14:01               ` Paolo Bonzini
2013-07-17 15:19           ` Gleb Natapov
2013-07-17 21:20             ` Eduardo Habkost

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51E586E6.1060001@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=aarcange@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=gleb@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-stable@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).