From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36835) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZDHEF-00081r-2W for qemu-devel@nongnu.org; Thu, 09 Jul 2015 15:11:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZDHE9-0007hx-Cm for qemu-devel@nongnu.org; Thu, 09 Jul 2015 15:11:27 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55489) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZDHE9-0007hs-7X for qemu-devel@nongnu.org; Thu, 09 Jul 2015 15:11:21 -0400 From: Bandan Das References: <559E1C8E.6080508@redhat.com> <20150709112728.38a953b6@nial.brq.redhat.com> <559E470C.9000301@redhat.com> Date: Thu, 09 Jul 2015 15:11:19 -0400 In-Reply-To: <559E470C.9000301@redhat.com> (Laszlo Ersek's message of "Thu, 09 Jul 2015 12:03:56 +0200") Message-ID: MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH] target-i386: Sanity check host processor physical address width List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laszlo Ersek Cc: Igor Mammedov , kvm@vger.kernel.org, qemu-devel@nongnu.org, Eduardo Habkost , Paolo Bonzini 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 ? > (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