From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:50733) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QgXBv-00012q-Bf for qemu-devel@nongnu.org; Tue, 12 Jul 2011 03:15:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QgXBr-0005WJ-0a for qemu-devel@nongnu.org; Tue, 12 Jul 2011 03:15:34 -0400 Received: from fmmailgate01.web.de ([217.72.192.221]:36437) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QgXBq-0005W5-2D for qemu-devel@nongnu.org; Tue, 12 Jul 2011 03:15:30 -0400 Message-ID: <4E1BF48F.9060302@web.de> Date: Tue, 12 Jul 2011 09:15:27 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1305826546-19059-4-git-send-email-stefano.stabellini@eu.citrix.com> <4E1B767E.7010606@web.de> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB187CAA5DA6786DCD9A5736D" Sender: jan.kiszka@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: Alexander Graf Cc: Stefan BOSAK , xen-devel Devel , "qemu-devel@nongnu.orgDevelopers Developers" , Stefano Stabellini This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB187CAA5DA6786DCD9A5736D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2011-07-12 08:28, Alexander Graf wrote: >=20 > On 12.07.2011, at 00:17, Jan Kiszka wrote: >=20 >> On 2011-05-19 19:35, stefano.stabellini@eu.citrix.com wrote: >>> From: Stefano Stabellini >>> >>> Introduce qemu_ram_ptr_length that takes an address and a size as >>> parameters rather than just an address. >>> >>> 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 th= at >>> 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 th= e >>> calls to qemu_get_ram_ptr with a single call to qemu_ram_ptr_length >>> passing a size argument. >> >> This breaks cpu_physical_memory_map for >4G addresses on PC. >> Effectively, it doesn't account for the PCI gap, ie. that the RAM bloc= k >> 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. >=20 > Yeah, that's what happens when you read mails too early in the morning = :). The xen branch didn't get pulled yet, so upstream is missing the foll= owing patch: >=20 > commit f221e5ac378feea71d9857ddaa40f829c511742f > Author: Stefano Stabellini > Date: Mon Jun 27 18:26:06 2011 +0100 >=20 > qemu_ram_ptr_length: take ram_addr_t as arguments > =20 > qemu_ram_ptr_length should take ram_addr_t as argument rather than > target_phys_addr_t because is doing comparisons with RAMBlock addre= sses. > =20 > cpu_physical_memory_map should create a ram_addr_t address to pass = to > qemu_ram_ptr_length from PhysPageDesc phys_offset. > =20 > Remove code after abort() in qemu_ram_ptr_length. > =20 > Changes in v2: > =20 > - handle 0 size in qemu_ram_ptr_length; > =20 > - rename addr1 to raddr; > =20 > - initialize raddr to ULONG_MAX. > =20 > Signed-off-by: Stefano Stabellini > Reviewed-by: Peter Maydell > Signed-off-by: Alexander Graf Maybe subject or changlog can reflect what this all fixes? >=20 > Anthony? Am I the only one under the impression that too many patches are in limbo ATM? Jan --------------enigB187CAA5DA6786DCD9A5736D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4b9I8ACgkQitSsb3rl5xSROwCgqzFD9SR2XnZUXyzj6Jbmv1eg hLUAnin86BgpEcpWczNTFOeETIiHgLal =CIB1 -----END PGP SIGNATURE----- --------------enigB187CAA5DA6786DCD9A5736D-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH v2 4/5] exec.c: refactor cpu_physical_memory_map Date: Tue, 12 Jul 2011 09:15:27 +0200 Message-ID: <4E1BF48F.9060302@web.de> References: <1305826546-19059-4-git-send-email-stefano.stabellini@eu.citrix.com> <4E1B767E.7010606@web.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0157938329==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Alexander Graf Cc: Stefan BOSAK , xen-devel Devel , "qemu-devel@nongnu.orgDevelopers Developers" , Anthony Liguori , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0157938329== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB187CAA5DA6786DCD9A5736D" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB187CAA5DA6786DCD9A5736D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2011-07-12 08:28, Alexander Graf wrote: >=20 > On 12.07.2011, at 00:17, Jan Kiszka wrote: >=20 >> On 2011-05-19 19:35, stefano.stabellini@eu.citrix.com wrote: >>> From: Stefano Stabellini >>> >>> Introduce qemu_ram_ptr_length that takes an address and a size as >>> parameters rather than just an address. >>> >>> 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 th= at >>> 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 th= e >>> calls to qemu_get_ram_ptr with a single call to qemu_ram_ptr_length >>> passing a size argument. >> >> This breaks cpu_physical_memory_map for >4G addresses on PC. >> Effectively, it doesn't account for the PCI gap, ie. that the RAM bloc= k >> 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. >=20 > Yeah, that's what happens when you read mails too early in the morning = :). The xen branch didn't get pulled yet, so upstream is missing the foll= owing patch: >=20 > commit f221e5ac378feea71d9857ddaa40f829c511742f > Author: Stefano Stabellini > Date: Mon Jun 27 18:26:06 2011 +0100 >=20 > qemu_ram_ptr_length: take ram_addr_t as arguments > =20 > qemu_ram_ptr_length should take ram_addr_t as argument rather than > target_phys_addr_t because is doing comparisons with RAMBlock addre= sses. > =20 > cpu_physical_memory_map should create a ram_addr_t address to pass = to > qemu_ram_ptr_length from PhysPageDesc phys_offset. > =20 > Remove code after abort() in qemu_ram_ptr_length. > =20 > Changes in v2: > =20 > - handle 0 size in qemu_ram_ptr_length; > =20 > - rename addr1 to raddr; > =20 > - initialize raddr to ULONG_MAX. > =20 > Signed-off-by: Stefano Stabellini > Reviewed-by: Peter Maydell > Signed-off-by: Alexander Graf Maybe subject or changlog can reflect what this all fixes? >=20 > Anthony? Am I the only one under the impression that too many patches are in limbo ATM? Jan --------------enigB187CAA5DA6786DCD9A5736D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4b9I8ACgkQitSsb3rl5xSROwCgqzFD9SR2XnZUXyzj6Jbmv1eg hLUAnin86BgpEcpWczNTFOeETIiHgLal =CIB1 -----END PGP SIGNATURE----- --------------enigB187CAA5DA6786DCD9A5736D-- --===============0157938329== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0157938329==--