From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:55711) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RisNN-00074W-IB for qemu-devel@nongnu.org; Thu, 05 Jan 2012 13:49:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RisNK-0007bs-MF for qemu-devel@nongnu.org; Thu, 05 Jan 2012 13:49:21 -0500 Received: from fmmailgate03.web.de ([217.72.192.234]:40323) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RisNK-0007be-AT for qemu-devel@nongnu.org; Thu, 05 Jan 2012 13:49:18 -0500 Received: from moweb002.kundenserver.de (moweb002.kundenserver.de [172.19.20.108]) by fmmailgate03.web.de (Postfix) with ESMTP id 4C4381AF400FA for ; Thu, 5 Jan 2012 19:49:16 +0100 (CET) Message-ID: <4F05F09E.8030800@web.de> Date: Thu, 05 Jan 2012 16:49:02 -0200 From: Jan Kiszka MIME-Version: 1.0 References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com> <1323467645-24271-6-git-send-email-anthony.perard@citrix.com> <4EE3382D.80903@web.de> <4EE609BF.1070307@siemens.com> <4EE617BA.4030102@siemens.com> <4EEE25DA.2080400@redhat.com> <4F048B10.1060505@redhat.com> <4F059C8C.2030303@redhat.com> <4F05A684.7000509@redhat.com> <4F05BF9E.7000203@redhat.com> <4F05D0BC.70707@redhat.com> <4F05E301.2020808@redhat.com> In-Reply-To: <4F05E301.2020808@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBFEEEA9BB7F5AAC4180D2E0B" Subject: Re: [Qemu-devel] [PATCH V2 5/5] vga-cirrus: Workaround during restore when using Xen. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Anthony Perard , Xen Devel , QEMU-devel , Stefano Stabellini This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBFEEEA9BB7F5AAC4180D2E0B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2012-01-05 15:50, Avi Kivity wrote: >> Let me summarize what we have come up with so far: >> >> - we move the call to xen_register_framebuffer before >> memory_region_init_ram in vga_common_init; >> >> - we prevent xen_ram_alloc from allocating a second framebuffer on >> restore, checking for mr =3D=3D framebuffer; >> >> - we avoid memsetting the framebuffer on restore (useless anyway, the >> videoram is going to be loaded from the savefile in the general case);= >> >> - we introduce a xen_address field to cirrus_vmstate and we use it >> to map the videoram into qemu's address space and update vram_ptr in >> cirrus_post_load. >> >> >> Does it make sense? Do you agree with the approach? >=20 > Yes and yes. To me this still sounds like a cirrus-only xen workaround that nevertheless spreads widely. Again, what speaks against migrating the information Xen needs before creating the machine or a single device? That would only introduce a generic concept of an (optional) "early", let's call it "accelerator-related" vmstate and would allow Xen to deal with all the specifics behind the curtain. Jan --------------enigBFEEEA9BB7F5AAC4180D2E0B 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.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8F8J8ACgkQitSsb3rl5xRekACdG5G/4+F5S9YF2J5imlmju8kV ZIEAoLhwol0x6yH/o1PsPBPkuDHu2CGf =U7wT -----END PGP SIGNATURE----- --------------enigBFEEEA9BB7F5AAC4180D2E0B--