From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [RFC v5 00/86] Memory API Date: Wed, 20 Jul 2011 23:43:34 +0200 Message-ID: <4E274C06.40902@web.de> References: <1311180636-17012-1-git-send-email-avi@redhat.com> <4E27132E.6080504@siemens.com> <4E2713C9.1030604@redhat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3F23CE55C776325EE9AA9AAA" Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org To: Avi Kivity Return-path: Received: from fmmailgate03.web.de ([217.72.192.234]:34572 "EHLO fmmailgate03.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751460Ab1GTVnj (ORCPT ); Wed, 20 Jul 2011 17:43:39 -0400 In-Reply-To: <4E2713C9.1030604@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3F23CE55C776325EE9AA9AAA Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable On 2011-07-20 19:43, Avi Kivity wrote: > On 07/20/2011 08:41 PM, Jan Kiszka wrote: >> On 2011-07-20 18:49, Avi Kivity wrote: >> > New in this version: >> > - more mindless conversions; I believe there are no longer any >> destructive >> > operations in the tree (IO_MEM_UNASSIGNED) >> > - fix memory map generation bug (patch 13) >> > - proper 440FX PAM/SMRAM and PCI holes >> > >> >> This on top fixes standard VGA dirty logging: >=20 > Both work for me without any patches. Impossible! ;) VGA frame buffer cannot work as no one enabled dirty logging for that range so far. Try -vga std with vga=3D0x314 in the guest. >=20 > Maybe the F15 window manager is polling the display? >=20 Only if that continuously enforces a full window refresh. As expected, there were dirty logging issues around removing a subregion on cirrus bank pointer updates. This makes linear vram mappings work again: diff --git a/memory.c b/memory.c index a8d4295..14fac8a 100644 --- a/memory.c +++ b/memory.c @@ -1093,9 +1093,26 @@ void memory_region_add_subregion_overlap(MemoryRegion *mr, void memory_region_del_subregion(MemoryRegion *mr, MemoryRegion *subregion) { + MemoryRegion *target_region; + ram_addr_t base, offs; + assert(subregion->parent =3D=3D mr); subregion->parent =3D NULL; QTAILQ_REMOVE(&mr->subregions, subregion, subregions_link); + + if (subregion->alias) { + base =3D subregion->alias_offset; + target_region =3D subregion->alias; + } else { + base =3D 0; + target_region =3D subregion; + } + if (target_region->dirty_log_mask) { + for (offs =3D 0; offs < subregion->size; offs +=3D TARGET_PAGE_S= IZE) { + memory_region_set_dirty(target_region, base + offs); + } + } + memory_region_update_topology(); } Debugging provided some more insights: - address_space_update_topology is not very successful in avoiding needless mapping updates. kvm_client_set_memory is called much more frequently than with the old code. - The region update pattern delete old / add new, e.g. to move the cirrus bank pointer, will never allow an optimal number of memory client calls. We either need some memory_region_update or a transaction API. I would favor the former, should also simplify the usage. - memory_region_update_topology should take a hint if all or just a specific address space need updating. - Something makes the startup of graphical grub under cirrus horribly slow, likely some bug that prevents linear vram mode during the screen setup. But once it is fully painted for the first time, grub feels as fast as with the old code. Jan --------------enig3F23CE55C776325EE9AA9AAA 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/ iEYEARECAAYFAk4nTAkACgkQitSsb3rl5xSn5QCg62VMAAFArtSpO0RQtDm+S3tw db0An1VhNM/iiYhpUY+mCra8WC+dEZ9j =Sju1 -----END PGP SIGNATURE----- --------------enig3F23CE55C776325EE9AA9AAA-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:52145) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QjeYS-00010d-5r for qemu-devel@nongnu.org; Wed, 20 Jul 2011 17:43:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QjeYP-0003X7-KR for qemu-devel@nongnu.org; Wed, 20 Jul 2011 17:43:43 -0400 Received: from fmmailgate03.web.de ([217.72.192.234]:34570) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QjeYO-0003Vj-Tf for qemu-devel@nongnu.org; Wed, 20 Jul 2011 17:43:41 -0400 Message-ID: <4E274C06.40902@web.de> Date: Wed, 20 Jul 2011 23:43:34 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1311180636-17012-1-git-send-email-avi@redhat.com> <4E27132E.6080504@siemens.com> <4E2713C9.1030604@redhat.com> In-Reply-To: <4E2713C9.1030604@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3F23CE55C776325EE9AA9AAA" Sender: jan.kiszka@web.de Subject: Re: [Qemu-devel] [RFC v5 00/86] Memory API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3F23CE55C776325EE9AA9AAA Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable On 2011-07-20 19:43, Avi Kivity wrote: > On 07/20/2011 08:41 PM, Jan Kiszka wrote: >> On 2011-07-20 18:49, Avi Kivity wrote: >> > New in this version: >> > - more mindless conversions; I believe there are no longer any >> destructive >> > operations in the tree (IO_MEM_UNASSIGNED) >> > - fix memory map generation bug (patch 13) >> > - proper 440FX PAM/SMRAM and PCI holes >> > >> >> This on top fixes standard VGA dirty logging: >=20 > Both work for me without any patches. Impossible! ;) VGA frame buffer cannot work as no one enabled dirty logging for that range so far. Try -vga std with vga=3D0x314 in the guest. >=20 > Maybe the F15 window manager is polling the display? >=20 Only if that continuously enforces a full window refresh. As expected, there were dirty logging issues around removing a subregion on cirrus bank pointer updates. This makes linear vram mappings work again: diff --git a/memory.c b/memory.c index a8d4295..14fac8a 100644 --- a/memory.c +++ b/memory.c @@ -1093,9 +1093,26 @@ void memory_region_add_subregion_overlap(MemoryRegion *mr, void memory_region_del_subregion(MemoryRegion *mr, MemoryRegion *subregion) { + MemoryRegion *target_region; + ram_addr_t base, offs; + assert(subregion->parent =3D=3D mr); subregion->parent =3D NULL; QTAILQ_REMOVE(&mr->subregions, subregion, subregions_link); + + if (subregion->alias) { + base =3D subregion->alias_offset; + target_region =3D subregion->alias; + } else { + base =3D 0; + target_region =3D subregion; + } + if (target_region->dirty_log_mask) { + for (offs =3D 0; offs < subregion->size; offs +=3D TARGET_PAGE_S= IZE) { + memory_region_set_dirty(target_region, base + offs); + } + } + memory_region_update_topology(); } Debugging provided some more insights: - address_space_update_topology is not very successful in avoiding needless mapping updates. kvm_client_set_memory is called much more frequently than with the old code. - The region update pattern delete old / add new, e.g. to move the cirrus bank pointer, will never allow an optimal number of memory client calls. We either need some memory_region_update or a transaction API. I would favor the former, should also simplify the usage. - memory_region_update_topology should take a hint if all or just a specific address space need updating. - Something makes the startup of graphical grub under cirrus horribly slow, likely some bug that prevents linear vram mode during the screen setup. But once it is fully painted for the first time, grub feels as fast as with the old code. Jan --------------enig3F23CE55C776325EE9AA9AAA 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/ iEYEARECAAYFAk4nTAkACgkQitSsb3rl5xSn5QCg62VMAAFArtSpO0RQtDm+S3tw db0An1VhNM/iiYhpUY+mCra8WC+dEZ9j =Sju1 -----END PGP SIGNATURE----- --------------enig3F23CE55C776325EE9AA9AAA--