From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=34356 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ovwmg-0007yj-CO for qemu-devel@nongnu.org; Wed, 15 Sep 2010 14:32:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OvwmU-0004nw-Dl for qemu-devel@nongnu.org; Wed, 15 Sep 2010 14:32:38 -0400 Received: from mail-pz0-f45.google.com ([209.85.210.45]:38999) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OvwmU-0004nf-74 for qemu-devel@nongnu.org; Wed, 15 Sep 2010 14:32:30 -0400 Received: by pzk12 with SMTP id 12so158469pzk.4 for ; Wed, 15 Sep 2010 11:32:28 -0700 (PDT) Message-ID: <4C910FC7.7060005@codemonkey.ws> Date: Wed, 15 Sep 2010 13:26:15 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] allow more than 1T in KVM x86 guest References: <20100915171335.GM5981@random.random> In-Reply-To: <20100915171335.GM5981@random.random> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andrea Arcangeli Cc: Anthony Liguori , qemu-devel@nongnu.org On 09/15/2010 12:13 PM, Andrea Arcangeli wrote: > Subject: allow more than 1T in KVM x86 guest > > From: Andrea Arcangeli > > When host supports 48 bits of physical address reflect that in the guest cpuid > to allow the guest to use more than 1TB of RAM. > > The migration code should probably be updated accordingly checking if the size > of the guest ram is bigger than the migration target cpuid 0x80000008 limit and > failing migration in that case. (not a real practical issue, I don't > see many people migrating>1T guests yet :) > > The comment below refers to a 42 bit limit on exec.c, but I didn't identify > what the comment refers to yet. At least now guest should be able to use 4TB. > target-i386/cpu.h #ifdef TARGET_X86_64 #define TARGET_PHYS_ADDR_SPACE_BITS 52 /* ??? This is really 48 bits, sign-extended, but the only thing accessible to userland with bit 48 set is the VSYSCALL, and that is handled via other mechanisms. */ #define TARGET_VIRT_ADDR_SPACE_BITS 47 #else #define TARGET_PHYS_ADDR_SPACE_BITS 36 #define TARGET_VIRT_ADDR_SPACE_BITS 32 #endif The macros are then used in exec.c Regards, Anthony Liguori > Signed-off-by: Andrea Arcangeli > --- > > diff --git a/target-i386/cpuid.c b/target-i386/cpuid.c > index d63fdcb..462e709 100644 > --- a/target-i386/cpuid.c > +++ b/target-i386/cpuid.c > @@ -1189,6 +1189,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->cpuid_features& CPUID_PSE36) > *eax = 0x00000024; /* 36 bits physical */ > >