From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35916) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xr4vC-00077j-8U for qemu-devel@nongnu.org; Wed, 19 Nov 2014 08:03:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xr4v3-0001wc-It for qemu-devel@nongnu.org; Wed, 19 Nov 2014 08:03:46 -0500 Date: Wed, 19 Nov 2014 23:57:23 +1100 From: David Gibson Message-ID: <20141119125723.GI2867@voom.redhat.com> References: <20141105071019.26196.93729.stgit@aravindap> <20141111032421.GH15270@voom.redhat.com> <546C2F4A.5010708@linux.vnet.ibm.com> <1E7E2B3B-7DD0-4B07-8C91-25C97D408D8A@suse.de> <20141119114437.GH2867@voom.redhat.com> <053929AE-91A7-434D-9326-C4C6B6F47792@suse.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/8E7gjuj425jZz9t" Content-Disposition: inline In-Reply-To: <053929AE-91A7-434D-9326-C4C6B6F47792@suse.de> Subject: Re: [Qemu-devel] [PATCH v3 0/4] target-ppc: Add FWNMI support in qemu for powerKVM guests List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: "benh@au1.ibm.com" , "aik@au1.ibm.com" , "qemu-devel@nongnu.org" , "qemu-ppc@nongnu.org" , Aravinda Prasad , "paulus@samba.org" --/8E7gjuj425jZz9t Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 19, 2014 at 01:22:01PM +0100, Alexander Graf wrote: >=20 >=20 >=20 > > Am 19.11.2014 um 12:44 schrieb David Gibson : > >=20 > >> On Wed, Nov 19, 2014 at 11:32:56AM +0100, Alexander Graf wrote: > >>=20 > >>=20 > >>=20 > >>> Am 19.11.2014 um 06:48 schrieb Aravinda Prasad : > >>>=20 > >>>=20 > >>>=20 > >>> On Tuesday 11 November 2014 08:54 AM, David Gibson wrote: > >>>=20 > >>> [..] > >>>=20 > >>>>=20 > >>>> So, this may not still be possible depending on whether the KVM side > >>>> of this is already merged, but it occurs to me that there's a simpler > >>>> way. > >>>>=20 > >>>> Rather than mucking about with having to update the hypervisor on the > >>>> RTAS location, they have qemu copy the code out of RTAS, patch it and > >>>> copy it back into the vector, you could instead do this: > >>>>=20 > >>>> 1. Make KVM instead of immediately delivering a 0x200 for a guest > >>>> machine check, cause a special exit to qemu. > >>>>=20 > >>>> 2. Have the register-nmi RTAS call store the guest side MC handler > >>>> address in the spapr structure, but perform no actual guest code > >>>> patching. > >>>>=20 > >>>> 3. Allocate the error log buffer independently from the RTAS blob, > >>>> so qemu always knows where it is. > >>>>=20 > >>>> 4. When qemu gets the MC exit condition, instead of going via a > >>>> patched 0x200 vector, just directly set the guest register state and > >>>> jump straight into the guest side MC handler. > >>>=20 > >>> Before I proceed further I would like to know what others think about > >>> the approach proposed above (except for step 3 - as per PAPR the error > >>> log buffer should be part of RTAS blob and hence we cannot have error > >>> log buffer independent of RTAS blob). > >>>=20 > >>> Alex, Alexey, Ben: Any thoughts? > >>=20 > >> If in doubt, stick to PAPR please. > >=20 > > Apart from (3), which was a misunderstanding on my part, this doesn't > > diverge from PAPR - it's just a question of how we're implementing the > > PAPR behaviour. >=20 > Do we need a guest handler at all? Couldn't we make MCs a new exit > type and handle it all straight from QEMU? Well, PAPR allows the OS to register a handler, which existing guests will expect to be able to do. The registered handler expects various information collated for it though, so it isn't a "raw" 0x200 vector. IIUC, traditionally pHyp implemented this by patching the guests 0x200 vector to collate the necessary information then jump to the supplied handler. I'm suggesting that instead we indeed make a new exit type, have qemu collate the information internally then jump directly back into the guest registered handler. I'm not sure if that's quite what you were suggesting, but I think we have pretty close to the same idea here. --=20 David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson --/8E7gjuj425jZz9t Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJUbJOzAAoJEGw4ysog2bOS2cAP/2yUXkh50tEQZiAy0M3VY99x 0RzIQIEJLSqznJsUj+NCyBPp8Y1cSZ0N/Z+HIGJpcA4joq7rs0McdMlTwS7pK1cM lKc9yPEGRqLrw/vQcLZmnUMe5RnJaqWipOElquComg01Q5x7kiLmM0jD2iRhldCO 4n+EcYQ+JdM3YHsYKQJkd7ZxMvlRQqnzeoDJFpDZLiLdqWHQ8D/nmKFuMhu6Tkw6 /gu+D+gP4ejUnG5Unuz+oeWQGcNU1KiH9T8YkWg6FqBH05RlOnc7fUhuCmaKDbb/ MH1I9scGYxa7SHU604fjZVoUIhpdYPtj7AtmQ9+MOLuhK8/XYZSmQpJVDEzBe7el UbCBsPoK8GhZzQPiI+bYx8WLnf/nUFZOjB7gIPIurSWh2Y9PiLUZdQdejWxZJqay pZx5GFjuepXZ2i5MWehQELZnHwOog+0htnUgMgHSC5/Exyh28Lu4o6BUvixozpqK aQqVGwMDi1SsWjdXO8YtCmcNl+21aqX6mcZrQ4MoD0/aUCU1yFOsTIAS1gH+288i d80h7EKcmJM+eY0vUsXO9GrLF+o+lFDH6lqjPQO7jBze1hspEYJsQKJ2nL/CXr0r cBCVqvLw20mdLKBwVfIkySVwy+xI+eF+1c0UBLOo4DrzHi87GJm1Ad3dPEJ37beO VMwV1Ev4il+Umr10qp+I =FMLy -----END PGP SIGNATURE----- --/8E7gjuj425jZz9t--