From: Anthony Liguori <anthony@codemonkey.ws>
To: Andrea Arcangeli <aarcange@redhat.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] allow more than 1T in KVM x86 guest
Date: Wed, 15 Sep 2010 13:26:15 -0500 [thread overview]
Message-ID: <4C910FC7.7060005@codemonkey.ws> (raw)
In-Reply-To: <20100915171335.GM5981@random.random>
On 09/15/2010 12:13 PM, Andrea Arcangeli wrote:
> Subject: allow more than 1T in KVM x86 guest
>
> From: Andrea Arcangeli<aarcange@redhat.com>
>
> 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<aarcange@redhat.com>
> ---
>
> 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 */
>
>
prev parent reply other threads:[~2010-09-15 18:32 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-15 17:13 [Qemu-devel] [PATCH] allow more than 1T in KVM x86 guest Andrea Arcangeli
2010-09-15 18:26 ` Anthony Liguori [this message]
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=4C910FC7.7060005@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=aarcange@redhat.com \
--cc=aliguori@us.ibm.com \
--cc=qemu-devel@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).