From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:43541) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RjD0O-0007d5-Bz for qemu-devel@nongnu.org; Fri, 06 Jan 2012 11:51:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RjD0K-0000h1-2m for qemu-devel@nongnu.org; Fri, 06 Jan 2012 11:51:00 -0500 Received: from fmmailgate03.web.de ([217.72.192.234]:44273) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RjD0I-0000gF-TU for qemu-devel@nongnu.org; Fri, 06 Jan 2012 11:50:55 -0500 Received: from moweb002.kundenserver.de (moweb002.kundenserver.de [172.19.20.108]) by fmmailgate03.web.de (Postfix) with ESMTP id 4CE491AF48C9F for ; Fri, 6 Jan 2012 17:50:53 +0100 (CET) Message-ID: <4F072664.3070000@web.de> Date: Fri, 06 Jan 2012 14:50:44 -0200 From: Jan Kiszka MIME-Version: 1.0 References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com> <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> <4F05F09E.8030800@web.de> <4F06F76F.7090002@web.de> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7D8EE30EADF2B9FB4905657F" 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: Peter Maydell Cc: Anthony Perard , QEMU-devel , Xen Devel , Avi Kivity , Stefano Stabellini This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7D8EE30EADF2B9FB4905657F Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2012-01-06 13:58, Peter Maydell wrote: > On 6 January 2012 13:30, Jan Kiszka wrote: >> The third point indicates that there is rather more generic room for >> improvements: Why should qemu reset device models before restore at al= l? >=20 > Commit 5a8a49d7aa says: > # if we load from a snapshot, the machine can be in any state. That can= > # cause troubles if loading an older image which does not carry all sta= te > # information the executing QEMU requires. Hardly any device takes care= of > # this scenario. >=20 > I think it's also easier to reason about devices if you know that the > device before a load was in a known clean state rather than being > anything at all. True, that's why we do this ATM. But issuing the reset globally without giving devices chance to handle this more precisely is just a suboptimal workaround, one that we may want to overcome at some point. Jan --------------enig7D8EE30EADF2B9FB4905657F 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/ iEYEARECAAYFAk8HJmQACgkQitSsb3rl5xQXbgCgln3tGCQ2ZxLyCAxIoM1X5Wfs vAYAoLCNzt56MjBceak1+pr+8ankm0Rz =8647 -----END PGP SIGNATURE----- --------------enig7D8EE30EADF2B9FB4905657F--