[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] target-i386: Sanity check host processor physic
From: |
Bandan Das |
Subject: |
Re: [Qemu-devel] [PATCH] target-i386: Sanity check host processor physical address width |
Date: |
Thu, 09 Jul 2015 15:11:19 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
Laszlo Ersek <address@hidden> 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
Re: [Qemu-devel] [PATCH] target-i386: Sanity check host processor physical address width, Paolo Bonzini, 2015/07/09
Re: [Qemu-devel] [PATCH] target-i386: Sanity check host processor physical address width, Igor Mammedov, 2015/07/09