From mboxrd@z Thu Jan 1 00:00:00 1970 From: Laszlo Ersek Subject: Re: [Qemu-devel] [PATCH] target-i386: Sanity check host processor physical address width Date: Thu, 09 Jul 2015 21:30:22 +0200 Message-ID: <559ECBCE.1050303@redhat.com> References: <559E1C8E.6080508@redhat.com> <20150709112728.38a953b6@nial.brq.redhat.com> <559E470C.9000301@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: Igor Mammedov , qemu-devel@nongnu.org, Paolo Bonzini , Eduardo Habkost , kvm@vger.kernel.org To: Bandan Das Return-path: Received: from mx1.redhat.com ([209.132.183.28]:41625 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753046AbbGITaY (ORCPT ); Thu, 9 Jul 2015 15:30:24 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On 07/09/15 21:11, Bandan Das wrote: > Laszlo Ersek 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 ? Please grep the tree for "above_4g_mem_size". The size of the 32-bit PCI hole is not constant, but all the necessary computation goes into "above_4g_mem_size" already. So I think you should derive the max possible gpa from "above_4g_mem_size" and the top of the hotpluggable memory area, and compare that against the PCPU address width, *if* EPT is enabled. (BTW "pcms->hotplug_memory.base" depends on "above_4g_mem_size" too.) Thanks Laszlo > >> (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