From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:50963) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QgWLo-0001S3-HQ for qemu-devel@nongnu.org; Tue, 12 Jul 2011 02:21:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QgWLj-0006C8-LE for qemu-devel@nongnu.org; Tue, 12 Jul 2011 02:21:43 -0400 Received: from cantor2.suse.de ([195.135.220.15]:49758 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QgWLj-0006C2-3P for qemu-devel@nongnu.org; Tue, 12 Jul 2011 02:21:39 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Alexander Graf In-Reply-To: <4E1B767E.7010606@web.de> Date: Tue, 12 Jul 2011 08:21:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1305826546-19059-4-git-send-email-stefano.stabellini@eu.citrix.com> <4E1B767E.7010606@web.de> Subject: Re: [Qemu-devel] [PATCH v2 4/5] exec.c: refactor cpu_physical_memory_map List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Stefan BOSAK , xen-devel@lists.xensource.com, qemu-devel@nongnu.org, stefano.stabellini@eu.citrix.com On 12.07.2011, at 00:17, Jan Kiszka wrote: > On 2011-05-19 19:35, stefano.stabellini@eu.citrix.com wrote: >> From: Stefano Stabellini >>=20 >> Introduce qemu_ram_ptr_length that takes an address and a size as >> parameters rather than just an address. >>=20 >> Refactor cpu_physical_memory_map so that we call qemu_ram_ptr_length = only >> once rather than calling qemu_get_ram_ptr one time per page. >> This is not only more efficient but also tries to simplify the logic = of >> the function. >> Currently we are relying on the fact that all the pages are mapped >> contiguously in qemu's address space: we have a check to make sure = that >> the virtual address returned by qemu_get_ram_ptr from the second call = on >> is consecutive. Now we are making this more explicit replacing all = the >> calls to qemu_get_ram_ptr with a single call to qemu_ram_ptr_length >> passing a size argument. >=20 > This breaks cpu_physical_memory_map for >4G addresses on PC. > Effectively, it doesn't account for the PCI gap, ie. that the RAM = block > is actually mapped in two chunks into the guest physical memory. One > outcome is that QEMU aborts when we try to process an address that is > now "outside" RAM. Simple to reproduce with a virtio NIC and 5G guest > memory, even without KVM. Ah, I see what you mean now. It breaks on current HEAD, but not on my = last xen-next branch which already included that patch, so I'd assume = it's something different that came in later. Alex From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Graf Subject: Re: [PATCH v2 4/5] exec.c: refactor cpu_physical_memory_map Date: Tue, 12 Jul 2011 08:21:36 +0200 Message-ID: References: <1305826546-19059-4-git-send-email-stefano.stabellini@eu.citrix.com> <4E1B767E.7010606@web.de> Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <4E1B767E.7010606@web.de> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jan Kiszka Cc: Stefan BOSAK , xen-devel@lists.xensource.com, qemu-devel@nongnu.org, stefano.stabellini@eu.citrix.com List-Id: xen-devel@lists.xenproject.org On 12.07.2011, at 00:17, Jan Kiszka wrote: > On 2011-05-19 19:35, stefano.stabellini@eu.citrix.com wrote: >> From: Stefano Stabellini >>=20 >> Introduce qemu_ram_ptr_length that takes an address and a size as >> parameters rather than just an address. >>=20 >> Refactor cpu_physical_memory_map so that we call qemu_ram_ptr_length = only >> once rather than calling qemu_get_ram_ptr one time per page. >> This is not only more efficient but also tries to simplify the logic = of >> the function. >> Currently we are relying on the fact that all the pages are mapped >> contiguously in qemu's address space: we have a check to make sure = that >> the virtual address returned by qemu_get_ram_ptr from the second call = on >> is consecutive. Now we are making this more explicit replacing all = the >> calls to qemu_get_ram_ptr with a single call to qemu_ram_ptr_length >> passing a size argument. >=20 > This breaks cpu_physical_memory_map for >4G addresses on PC. > Effectively, it doesn't account for the PCI gap, ie. that the RAM = block > is actually mapped in two chunks into the guest physical memory. One > outcome is that QEMU aborts when we try to process an address that is > now "outside" RAM. Simple to reproduce with a virtio NIC and 5G guest > memory, even without KVM. Ah, I see what you mean now. It breaks on current HEAD, but not on my = last xen-next branch which already included that patch, so I'd assume = it's something different that came in later. Alex