From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LDGzu-0006Q8-DX for qemu-devel@nongnu.org; Thu, 18 Dec 2008 06:24:54 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LDGzt-0006Pw-Pg for qemu-devel@nongnu.org; Thu, 18 Dec 2008 06:24:54 -0500 Received: from [199.232.76.173] (port=55105 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LDGzt-0006Pt-Jt for qemu-devel@nongnu.org; Thu, 18 Dec 2008 06:24:53 -0500 Received: from mx2.redhat.com ([66.187.237.31]:43533) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LDGzs-0005DB-VJ for qemu-devel@nongnu.org; Thu, 18 Dec 2008 06:24:53 -0500 Message-ID: <494A32FF.80103@redhat.com> Date: Thu, 18 Dec 2008 13:24:47 +0200 From: Avi Kivity MIME-Version: 1.0 References: <1229546822-11972-1-git-send-email-glommer@redhat.com> <1229546822-11972-2-git-send-email-glommer@redhat.com> <1229546822-11972-3-git-send-email-glommer@redhat.com> <1229546822-11972-4-git-send-email-glommer@redhat.com> <1229546822-11972-5-git-send-email-glommer@redhat.com> <1229546822-11972-6-git-send-email-glommer@redhat.com> <494A1AC4.30704@redhat.com> <20081218104850.GB19123@poweredge.glommer> In-Reply-To: <20081218104850.GB19123@poweredge.glommer> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 5/5] cache slot lookup Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Glauber Costa Cc: Ian.Jackson@eu.citrix.com, qemu-devel@nongnu.org, kvm@vger.kernel.org, stefano.stabellini@eu.citrix.com Glauber Costa wrote: >> This wasn't introduced by this patch, but the comparison is broken ion >> i386 hosts, where target_phys_addr_t is 32 bits wide. mem->start_addr + >> mem->memory_size can overflow (this in fact happens for the bios slot at >> 4G-128K) >> > AFAIK, the assumption is that kvm will always be qemu-system-x86_64, due to > migration issues. That's an incorrect assumption. Users are free to build any qemu variant they like. 32-bit qemu ought to work. > Then, _target_ phys_addr_t is always 64 bit wide. > It is not. On a 32-bit host, qemu-system-x87_43's target_phys_addr_t is 32 bits wide. > If it's not the case, then this is really a problem. > It isn't, so it is. I hacked around it in kvm-userspace. -- error compiling committee.c: too many arguments to function