From: Laszlo Ersek <lersek@redhat.com>
To: Bandan Das <bsd@redhat.com>, qemu-devel@nongnu.org
Cc: kvm@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
Eduardo Habkost <ehabkost@redhat.com>
Subject: Re: [PATCH] target-i386: Sanity check host processor physical address width
Date: Thu, 09 Jul 2015 09:02:38 +0200 [thread overview]
Message-ID: <559E1C8E.6080508@redhat.com> (raw)
In-Reply-To: <jpgy4iqi85i.fsf@linux.bootlegged.copy>
On 07/09/15 00:42, Bandan Das wrote:
>
> If a Linux guest is assigned more memory than is supported
> by the host processor, the guest is unable to boot. That
> is expected, however, there's no message indicating the user
> what went wrong. This change prints a message to stderr if
> KVM has the corresponding capability.
>
> Reported-by: Laszlo Ersek <lersek@redhat.com>
> Signed-off-by: Bandan Das <bsd@redhat.com>
> ---
> linux-headers/linux/kvm.h | 1 +
> target-i386/kvm.c | 6 ++++++
> 2 files changed, 7 insertions(+)
>
> diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
> index 3bac873..6afad49 100644
> --- a/linux-headers/linux/kvm.h
> +++ b/linux-headers/linux/kvm.h
> @@ -817,6 +817,7 @@ struct kvm_ppc_smmu_info {
> #define KVM_CAP_DISABLE_QUIRKS 116
> #define KVM_CAP_X86_SMM 117
> #define KVM_CAP_MULTI_ADDRESS_SPACE 118
> +#define KVM_CAP_PHY_ADDR_WIDTH 119
>
> #ifdef KVM_CAP_IRQ_ROUTING
>
> diff --git a/target-i386/kvm.c b/target-i386/kvm.c
> index 066d03d..66e3448 100644
> --- a/target-i386/kvm.c
> +++ b/target-i386/kvm.c
> @@ -892,6 +892,7 @@ int kvm_arch_init(MachineState *ms, KVMState *s)
> uint64_t shadow_mem;
> int ret;
> struct utsname utsname;
> + int max_phys_bits;
>
> ret = kvm_get_supported_msrs(s);
> if (ret < 0) {
> @@ -945,6 +946,11 @@ int kvm_arch_init(MachineState *ms, KVMState *s)
> }
> }
>
> + max_phys_bits = kvm_check_extension(s, KVM_CAP_PHY_ADDR_WIDTH);
> + if (max_phys_bits && (1ULL << max_phys_bits) <= ram_size)
> + fprintf(stderr, "Warning: The amount of memory assigned to the guest "
> + "is more than that supported by the host CPU(s). Guest may be unstable.\n");
> +
> if (kvm_check_extension(s, KVM_CAP_X86_SMM)) {
> smram_machine_done.notify = register_smram_listener;
> qemu_add_machine_init_done_notifier(&smram_machine_done);
>
First, see my comments on the KVM patch.
Second, ram_size is not the right thing to compare. What should be
checked is whether the highest guest-physical address that maps to RAM
can be represented in the address width of the host processor (and only
if EPT is enabled, but that sub-condition belongs to the KVM patch).
Note that this is not the same as the check written in the patch. For
example, if you assume a 32-bit PCI hole with size 1 GB, then a total
guest RAM of size 63 GB will result in the highest guest-phys memory
address being 0xF_FFFF_FFFF, which just fits into 36 bits.
Correspondingly, the above code would not print the warning for
-m $((63 * 1024 + 1))
on my laptop (which has "address sizes : 36 bits physical, ..."), even
though such a guest would not boot for me (with EPT enabled).
Please see
http://thread.gmane.org/gmane.comp.bios.tianocore.devel/15418/focus=15447
So, "ram_size" in the controlling expression should be replaced with
"maximum_guest_ram_address" (which should be inclusive, and the <= relop
should be preserved).
Thanks
Laszlo
WARNING: multiple messages have this Message-ID (diff)
From: Laszlo Ersek <lersek@redhat.com>
To: Bandan Das <bsd@redhat.com>, qemu-devel@nongnu.org
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Eduardo Habkost <ehabkost@redhat.com>,
kvm@vger.kernel.org
Subject: Re: [Qemu-devel] [PATCH] target-i386: Sanity check host processor physical address width
Date: Thu, 09 Jul 2015 09:02:38 +0200 [thread overview]
Message-ID: <559E1C8E.6080508@redhat.com> (raw)
In-Reply-To: <jpgy4iqi85i.fsf@linux.bootlegged.copy>
On 07/09/15 00:42, Bandan Das wrote:
>
> If a Linux guest is assigned more memory than is supported
> by the host processor, the guest is unable to boot. That
> is expected, however, there's no message indicating the user
> what went wrong. This change prints a message to stderr if
> KVM has the corresponding capability.
>
> Reported-by: Laszlo Ersek <lersek@redhat.com>
> Signed-off-by: Bandan Das <bsd@redhat.com>
> ---
> linux-headers/linux/kvm.h | 1 +
> target-i386/kvm.c | 6 ++++++
> 2 files changed, 7 insertions(+)
>
> diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
> index 3bac873..6afad49 100644
> --- a/linux-headers/linux/kvm.h
> +++ b/linux-headers/linux/kvm.h
> @@ -817,6 +817,7 @@ struct kvm_ppc_smmu_info {
> #define KVM_CAP_DISABLE_QUIRKS 116
> #define KVM_CAP_X86_SMM 117
> #define KVM_CAP_MULTI_ADDRESS_SPACE 118
> +#define KVM_CAP_PHY_ADDR_WIDTH 119
>
> #ifdef KVM_CAP_IRQ_ROUTING
>
> diff --git a/target-i386/kvm.c b/target-i386/kvm.c
> index 066d03d..66e3448 100644
> --- a/target-i386/kvm.c
> +++ b/target-i386/kvm.c
> @@ -892,6 +892,7 @@ int kvm_arch_init(MachineState *ms, KVMState *s)
> uint64_t shadow_mem;
> int ret;
> struct utsname utsname;
> + int max_phys_bits;
>
> ret = kvm_get_supported_msrs(s);
> if (ret < 0) {
> @@ -945,6 +946,11 @@ int kvm_arch_init(MachineState *ms, KVMState *s)
> }
> }
>
> + max_phys_bits = kvm_check_extension(s, KVM_CAP_PHY_ADDR_WIDTH);
> + if (max_phys_bits && (1ULL << max_phys_bits) <= ram_size)
> + fprintf(stderr, "Warning: The amount of memory assigned to the guest "
> + "is more than that supported by the host CPU(s). Guest may be unstable.\n");
> +
> if (kvm_check_extension(s, KVM_CAP_X86_SMM)) {
> smram_machine_done.notify = register_smram_listener;
> qemu_add_machine_init_done_notifier(&smram_machine_done);
>
First, see my comments on the KVM patch.
Second, ram_size is not the right thing to compare. What should be
checked is whether the highest guest-physical address that maps to RAM
can be represented in the address width of the host processor (and only
if EPT is enabled, but that sub-condition belongs to the KVM patch).
Note that this is not the same as the check written in the patch. For
example, if you assume a 32-bit PCI hole with size 1 GB, then a total
guest RAM of size 63 GB will result in the highest guest-phys memory
address being 0xF_FFFF_FFFF, which just fits into 36 bits.
Correspondingly, the above code would not print the warning for
-m $((63 * 1024 + 1))
on my laptop (which has "address sizes : 36 bits physical, ..."), even
though such a guest would not boot for me (with EPT enabled).
Please see
http://thread.gmane.org/gmane.comp.bios.tianocore.devel/15418/focus=15447
So, "ram_size" in the controlling expression should be replaced with
"maximum_guest_ram_address" (which should be inclusive, and the <= relop
should be preserved).
Thanks
Laszlo
next prev parent reply other threads:[~2015-07-09 7:02 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-08 22:42 [PATCH] target-i386: Sanity check host processor physical address width Bandan Das
2015-07-08 22:42 ` [Qemu-devel] " Bandan Das
2015-07-09 7:02 ` Laszlo Ersek [this message]
2015-07-09 7:02 ` Laszlo Ersek
2015-07-09 9:27 ` Igor Mammedov
2015-07-09 9:27 ` Igor Mammedov
2015-07-09 10:03 ` Laszlo Ersek
2015-07-09 10:03 ` Laszlo Ersek
2015-07-09 19:11 ` Bandan Das
2015-07-09 19:11 ` Bandan Das
2015-07-09 19:30 ` Laszlo Ersek
2015-07-09 19:30 ` Laszlo Ersek
2015-07-09 7:59 ` Paolo Bonzini
2015-07-09 7:59 ` [Qemu-devel] " Paolo Bonzini
2015-07-09 8:26 ` Laszlo Ersek
2015-07-09 8:26 ` [Qemu-devel] " Laszlo Ersek
2015-07-09 13:04 ` Paolo Bonzini
2015-07-09 13:04 ` [Qemu-devel] " Paolo Bonzini
2015-07-09 19:22 ` Bandan Das
2015-07-09 19:22 ` [Qemu-devel] " Bandan Das
2015-07-09 12:51 ` Igor Mammedov
2015-07-09 12:51 ` Igor Mammedov
2015-07-09 19:25 ` Bandan Das
2015-07-09 19:25 ` Bandan Das
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=559E1C8E.6080508@redhat.com \
--to=lersek@redhat.com \
--cc=bsd@redhat.com \
--cc=ehabkost@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.