From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47880) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZXMhx-0003wW-DB for qemu-devel@nongnu.org; Thu, 03 Sep 2015 01:05:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZXMhv-0008GR-OI for qemu-devel@nongnu.org; Thu, 03 Sep 2015 01:05:09 -0400 Date: Thu, 3 Sep 2015 15:05:21 +1000 From: David Gibson Message-ID: <20150903050521.GK6537@voom.redhat.com> References: <55950058.8040508@ozlabs.ru> <20150703060102.GB16378@voom.redhat.com> <559CDF1D.9090103@linux.vnet.ibm.com> <20150807033745.GA4645@tungsten.ozlabs.ibm.com> <55C75B3E.70409@suse.de> <20150810040555.GA9392@tungsten.ozlabs.ibm.com> <55E58707.1030904@linux.vnet.ibm.com> <20150902063401.GA12512@tungsten.ozlabs.ibm.com> <20150902235320.GC6537@voom.redhat.com> <20150903032421.GA4355@tungsten.ozlabs.ibm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lZZ4ablUVnt2XgAh" Content-Disposition: inline In-Reply-To: <20150903032421.GA4355@tungsten.ozlabs.ibm.com> Subject: Re: [Qemu-devel] [Qemu-ppc] [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: Sam Bobroff Cc: benh@au1.ibm.com, Alexander Graf , qemu-devel@nongnu.org, qemu-ppc@nongnu.org, Aravinda Prasad , paulus@samba.org --lZZ4ablUVnt2XgAh Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 03, 2015 at 01:24:21PM +1000, Sam Bobroff wrote: > On Thu, Sep 03, 2015 at 09:53:20AM +1000, David Gibson wrote: > > On Wed, Sep 02, 2015 at 04:34:01PM +1000, Sam Bobroff wrote: > > > On Tue, Sep 01, 2015 at 04:37:51PM +0530, Aravinda Prasad wrote: > > > >=20 > > > >=20 > > > > On Monday 10 August 2015 09:35 AM, Sam Bobroff wrote: > > > > > On Sun, Aug 09, 2015 at 03:53:02PM +0200, Alexander Graf wrote: > > > > >> > > > > >> > > > > >> On 07.08.15 05:37, Sam Bobroff wrote: > > [snip] > > > > >>> (c) Assemble it (as above) but include it directly in the QEMU = binary by > > > > >>> objcopying it in or hexdumping into a C string or something sim= ilar. This seems > > > > >>> fairly neat but I'm not sure how people would feel about includ= ing "binaries" > > > > >>> into QEMU this way. Although it would take some work in the bu= ild system, it > > > > >>> seems like a fairly neat solution to me. > > > > >> > > > > >> We tried to move away from code as hex arrays in QEMU to make it= easier > > > > >> for people to patch things when they want to. But then again if = we're > > > > >> talking 3 instructions it might not be the worst option. > > > > >=20 > > > > > Sounds sensible. > > > > >=20 > > > > > So, in summary, it sounds like a decent approach would be: > > > > > * store the guest's handlers in QEMU's spapr structure, > > > > > * simplify the trampolines down to a single, non-returning, hcall, > > > >=20 > > > > However, other instructions such as saving r3 and re-trying hcall a= re > > > > still required. > > >=20 > > > Ah yes, that's true. I was thinking that the retrying could happen in= side the > > > hcall but it can't. > >=20 > > Sorry, I may have missed something here. What does the code in the > > vector need to retry? >=20 > It's due to having to handle simtaneous machine checks and there being a = single > shared buffer for reporting the error. PAPR isn't very specific but here = is > what it says (from section 7.3.14): >=20 > Multiple processors of the same OS image may experi- ence fatal events at= , or > about, the same time. The first processor to enter the machine check hand= ling > firmware reports the fatal error. Subsequent processors serialize waiting= for > the first processor to issue the ibm,nmi-interlock call. These subsequent > processors report =E2=80=9Cfatal error previously reported=E2=80=9D. If, = after the firmware > makes a Machine Check call back, and before the OS issues the ibm,nmi-int= erlock > call, the same processor that is currently holding the storage containing= the > error log structure receives another Machine Check NMI, the firmware has = no > choice but to declare the condition fatal, log the result and execute the > partition=E2=80=99s reboot policy. >=20 > So it needs to retry setting up the error buffer until it succeeds. Hm.. so why can't the hypervisor code do the retrying? > > Also, it looks like the vector will need at least one scratch register > > (for the hcall number, if nothing else). Does PAPR specify what SPRGs > > the vector can clobber? Obviously it can't be anything the guest > > kernel uses. >=20 > PAPR only says SPRGs 0 to 3 are for software use, but the kernel (see > arch/powerpc/include/asm/reg.h) defines SPRG2 as an exception scratch reg= ister > so it should be the right one to use here. Uh.. no. If 0..3 are for software (i.e. OS) use, then this needs to use a different one, since it's being used as a firmware resource here. Linux might treat SPRG2 as scratch, but another OS would be within its rights to use it for something persistent. Although, as paulus points out, sc 1 will clobber SRR0/1 anyway, and if we use a special illegal instruction, then you no longer need a scratch register. > > Btw, does anyone know what happens with the VPA (and dispatch trace > > log and so forth) on kexec() - it could be subject to the same stale > > address problem, and rewriting vectors won't save us there. >=20 > I asked Michael Ellerman this one and he thinks kexec probably frees and > re-allocates the VPA. Ok. So the question is: if an explicit deregister is good enough for the VPA, is it also good enough for the FWNMI vector, in which case doing it with just a qemu exit and not bouncing through the guest space is back on the table. I guess that's still problematic because there are existing guests that assume a kexec() will magically wipe the fwnmi vectors away. --=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 --lZZ4ablUVnt2XgAh Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJV59URAAoJEGw4ysog2bOSBcwQALZyH3vAzmeEPSL4agf0cewK Mt/yd5Isxo+pj3F8nxbe1we8mkH0pz0SnQhi+qqcMc4qbLUMbqwd3G+oshVllPet EFfZAaxK4VY3SMyYDFOiaoOeEUen0MXdki32KUdc4sTARBmae5DIznFjAmaISawt RnyPiTgj9rubS+TLFDOshmJGVGqEy0nCj8zZ1X+mGp59LH07TANwFxFuVRg30RP/ v70Or+b5VbJYwgHfpVD8b0X/gewL4VZwLIHoBPeID8FMYUFheQNLDBHRBsgWOPQl Ig9bXRrDUKNcDtL8PFVPLhpscNLolQexrClqBJH4jbW1cH+uS2WeOvNYhokFG0YH Rx473t9LUZYrZXMSkePaO4+l3gRv4gCaUiGn7rxoOLL+1rh1LFLVZDayubEuRmJg +KrpUNrySXJr5ufJmfFBCjyY6WJuMztbFP3CB8v2Vz0jyvrE16mF98n+P1kdsyTl IiiV6Bz+VT0yqPGPpTPdN4+IPg35CmkuPwPOs3AcAflc7bRwD3GDso/Bbj1SZceQ jUs38j+2fj3UcRJTUIAaKLKBOJHYzRZ26PPZlbOsgP+D8Eap+ioSOOqZbP51/DHu l13GYG2RaO6TQ/RtXtMm4WMqNf8E5aArhaBbwGAEgtF4Q6H5FgNkXIm5G8bAwUUN JPCsVPLBCRx8FcMxsPZ3 =fii3 -----END PGP SIGNATURE----- --lZZ4ablUVnt2XgAh--