From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [RFC][PATCH] qemu-kvm: Introduce writeback scope for cpu_synchronize_state Date: Mon, 16 Nov 2009 22:22:56 +0100 Message-ID: <4B01C2B0.3000205@web.de> References: <4B018542.3020602@siemens.com> <4B01A487.3020808@redhat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8685E92BEB39BB9800074C3F" Cc: Marcelo Tosatti , kvm , Gleb Natapov To: Avi Kivity Return-path: Received: from fmmailgate03.web.de ([217.72.192.234]:41262 "EHLO fmmailgate03.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751267AbZKPVWw (ORCPT ); Mon, 16 Nov 2009 16:22:52 -0500 In-Reply-To: <4B01A487.3020808@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8685E92BEB39BB9800074C3F Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Avi Kivity wrote: > On 11/16/2009 07:00 PM, Jan Kiszka wrote: >> This patch aims at addressing the mp_state writeback issue in a cleane= r >> fashion. >=20 > What's the issue? the fact that mp_state is updated whenever state is > synchronized, while it could be simultaneously updated from other vcpus= > (which latter updates are then lost)? Right, the issue b8a7857071 addressed. But that approach spreads more kvm_* fragments in unrelated qemu code, e.g. the monitor, and fails to update other parts (gdbstub). And it doesn't care about what happens if kvm is off at build or runtime. Such things are better addressed in upstream by encapsulating kvm calls in synchronization points. >=20 >> By introducing additional information about the scope of the >> scheduled vcpu state writeback, we can simply skin mp_state (and maybe= >> other specific states in the future) when updating the in-kernel state= =2E >> >> The writeback scope is defined when calling cpu_synchronize_state. It >> accumulated, ie. once a full writeback was requested, this will stick >> until it was performed. >> =20 >=20 > Maybe it's just simpler to divorce mp_state from the rest of the state.= That won't solve the core issue. mp_state *is* part of the state, and needs to be read (to update halted) and sometimes also written when the state was hard reset. Jan --------------enig8685E92BEB39BB9800074C3F 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.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAksBwrAACgkQitSsb3rl5xQnDQCcCmTEraplOYnpMW+crYaWQEMJ 3CgAn2wxNqYtU4vzbDavRBaOBi0nV1AK =rVla -----END PGP SIGNATURE----- --------------enig8685E92BEB39BB9800074C3F--