From: Bandan Das <bsd@redhat.com>
To: Laszlo Ersek <lersek@redhat.com>
Cc: Igor Mammedov <imammedo@redhat.com>,
qemu-devel@nongnu.org, 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 15:11:19 -0400 [thread overview]
Message-ID: <jpgtwtd6t9k.fsf@linux.bootlegged.copy> (raw)
In-Reply-To: <559E470C.9000301@redhat.com> (Laszlo Ersek's message of "Thu, 09 Jul 2015 12:03:56 +0200")
Laszlo Ersek <lersek@redhat.com> writes:
...
>>>
>>> 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).
>> also with memory hotplug tuned on we should check if the end of
>> hotplug memory area is less then limit, i.e.:
>>
>> pcms->hotplug_memory.base + hotplug_mem_size < 1ULL << max_phys_bits
>
> Seems reasonable, thanks for the hint!
Thanks Igor and Laszlo, makes sense. I am wondering if this 1GB PCI
hole is always fixed so that I can simply include that in calculating the maximum
guest ram address ? Or do we have to figure that out every time ?
> (The LHS in this instance is exclusive though, so equality should *not*
> trigger the warning. "maximum_guest_ram_address" is inclusive, and
> equality should trigger the warning. (Although equality seems quite
> impossible in practice.))
>
> Thanks!
> Laszlo
WARNING: multiple messages have this Message-ID (diff)
From: Bandan Das <bsd@redhat.com>
To: Laszlo Ersek <lersek@redhat.com>
Cc: Igor Mammedov <imammedo@redhat.com>,
kvm@vger.kernel.org, qemu-devel@nongnu.org,
Eduardo Habkost <ehabkost@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] target-i386: Sanity check host processor physical address width
Date: Thu, 09 Jul 2015 15:11:19 -0400 [thread overview]
Message-ID: <jpgtwtd6t9k.fsf@linux.bootlegged.copy> (raw)
In-Reply-To: <559E470C.9000301@redhat.com> (Laszlo Ersek's message of "Thu, 09 Jul 2015 12:03:56 +0200")
Laszlo Ersek <lersek@redhat.com> writes:
...
>>>
>>> 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).
>> also with memory hotplug tuned on we should check if the end of
>> hotplug memory area is less then limit, i.e.:
>>
>> pcms->hotplug_memory.base + hotplug_mem_size < 1ULL << max_phys_bits
>
> Seems reasonable, thanks for the hint!
Thanks Igor and Laszlo, makes sense. I am wondering if this 1GB PCI
hole is always fixed so that I can simply include that in calculating the maximum
guest ram address ? Or do we have to figure that out every time ?
> (The LHS in this instance is exclusive though, so equality should *not*
> trigger the warning. "maximum_guest_ram_address" is inclusive, and
> equality should trigger the warning. (Although equality seems quite
> impossible in practice.))
>
> Thanks!
> Laszlo
next prev parent reply other threads:[~2015-07-09 19:11 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
2015-07-09 7:02 ` [Qemu-devel] " 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 [this message]
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=jpgtwtd6t9k.fsf@linux.bootlegged.copy \
--to=bsd@redhat.com \
--cc=ehabkost@redhat.com \
--cc=imammedo@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=lersek@redhat.com \
--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.