From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49343) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xr44B-0001SL-Jw for qemu-devel@nongnu.org; Wed, 19 Nov 2014 07:09:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xr449-0008FH-Cg for qemu-devel@nongnu.org; Wed, 19 Nov 2014 07:08:59 -0500 Date: Wed, 19 Nov 2014 22:44:37 +1100 From: David Gibson Message-ID: <20141119114437.GH2867@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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1EKig6ypoSyM7jaD" Content-Disposition: inline In-Reply-To: <1E7E2B3B-7DD0-4B07-8C91-25C97D408D8A@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" --1EKig6ypoSyM7jaD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. 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 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 --1EKig6ypoSyM7jaD Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJUbIKlAAoJEGw4ysog2bOSEYUQAJjpwR9uMrIadTmQVHq5cjt8 o2AJrcHcOYjWUl3GGUGxP355pVqQRLfWSOFN7v82HFrNJJwm75PLUTaFSgtKr8jd 3eKTldg/guS+ewQxzNvgBe6nT7+WjP+osZp3EUP2460SI3jEpVqkSPHrDW6fCwUh M3ZqcLXFrtPROQs0UhGHvALkJL5rAoS1BMP7gkOl7taiude4FC8Hes0j6+S9D4Ca sKaav4JtGt9NWa6hyRxqabK83xRxbu/DXmV4YZPrNAnZFaYUAFHg+SP+/SSfTShN XsJ+FOvdu8HTJgKhqFnCS+Okb31v8vHm8X3O+dx7+CV4Oxj9iIFXxvKk858ihqMb ifbtLTFIixRQLGZzy8ygHVqmTCZciU9wjvtZbnnncIAfvXHoMF3IJ+W3bvVDnR1N G7FaysZlugSYa3WwI+/Yk7jxnCK4g7WGha5XgB9yeiHCbdSdUWVzJJMrs7gnN+5h AUOlf2CN4Vls4bI+MhT2YFeLNGJo6cg/MBTglkS8RyFBwM5nx5HAbeIafvYTKDUv Bws5SbPuxL0F05YXJmA5zCn+Ujnh1VPNc2Y+aunQL0xYN9DsgOIBmzEEtqUoMUFr bv1DczVtWmPnpuEtET33VbXPLfi5oI+7CZWGXJKJzRuG5sBzbNVCeShW0hGk57AA KbYZ349AI1kGiZFeVpy2 =KLMQ -----END PGP SIGNATURE----- --1EKig6ypoSyM7jaD--