From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49344) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZXj9I-0007qX-Uf for qemu-devel@nongnu.org; Fri, 04 Sep 2015 01:02:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZXj9H-0005fO-Lm for qemu-devel@nongnu.org; Fri, 04 Sep 2015 01:02:52 -0400 Date: Fri, 4 Sep 2015 15:01:34 +1000 From: David Gibson Message-ID: <20150904050134.GT6537@voom.redhat.com> References: <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> <20150903050521.GK6537@voom.redhat.com> <20150903062222.GA16268@tungsten.ozlabs.ibm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5tINJiUS2/Dn5Rhr" Content-Disposition: inline In-Reply-To: <20150903062222.GA16268@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: Aravinda Prasad , benh@au1.ibm.com, qemu-ppc@nongnu.org, qemu-devel@nongnu.org, paulus@samba.org --5tINJiUS2/Dn5Rhr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 03, 2015 at 04:22:22PM +1000, Sam Bobroff wrote: > On Thu, Sep 03, 2015 at 03:05:21PM +1000, David Gibson wrote: >=20 > [snip] >=20 > > Hm.. so why can't the hypervisor code do the retrying? >=20 > Aravinda replied to this earlier in the thread: >=20 > "Retrying cannot be done internally in h_report_mc_err hcall: only one > thread can succeed entering qemu upon parallel hcall and hence retrying > inside the hcall will not allow the ibm,nmi-interlock from first CPU to > succeed." >=20 > I assume that this means that the big QEMU lock is held while an hcall is > processed by QEMU, but I haven't checked the code myself. Actually, even = if the > lock is normally held, I don't see why these particular hcalls couldn't r= elease > the lock. I'll look into this. Yes, you should be able to release the BQL in the hcall in order to do retries internally. Thomas Huth's draft H_RANDOM implementation does something similar, since it can block > > > > Also, it looks like the vector will need at least one scratch regis= ter > > > > (for the hcall number, if nothing else). Does PAPR specify what SP= RGs > > > > 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= register > > > so it should be the right one to use here. > >=20 > > 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. > >=20 > > 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. > >=20 > > > > 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. > >=20 > > 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. > >=20 > > I guess that's still problematic because there are existing guests > > that assume a kexec() will magically wipe the fwnmi vectors away. >=20 > Yes, but I think we could handle this separately if necessary: even if we= don't > need to write anything to the vector, we could still insert a magic value= and > check for it later. If it's been clobbered by a kexec, go back to the old > method. True. Of course if you're going to do that, it makes sense to make the value a a distinguishable illegal instrucion anyway. --=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 --5tINJiUS2/Dn5Rhr Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJV6SWuAAoJEGw4ysog2bOS6ocQAMBTRNXdKRfKNCEJAEHtCr1M t1sJ9S/kRROmFPiOgYyOJWXCBEVTySPrfts3hBfElEubyJlOIJ4wNORgZmvzmyCY hZt5O4DLA3npuKpPtSSkBDGyzF4MLn/x6nWaOULCkuapIkFWE7gkkRQZx7N1LE0K ymWskWUlCOAlYn4WBojvRvroin1bjFR62ZwbV8D+P2T96By2KUnoEZjLz37rmfyh 25G4tIto8YzKAip1shJs2GMQZ3gAoz1fdFtwGhvALM3/Hy9w4ZJT4nFm4q+FwHyp 4J16vuQxOXZ3B2xYlXr2uDj1MhjyzQqUVIR4PFcr3i5O57ouqFAYnvWD9uFiZx/F Yg+OB0ZRkSK/4yKKZi0UZLf4iAy0lhGjOiEO0mwEfCgAOCvx52Fvc3Vz1LTCRYFx G63aEawdxIHZb2Ecv7LTzWvUSQsbjINTisPFcsSQ7tO5lttKLf/iIMgTZQeP6dSJ gY7OwOsL5DzZJJFqR3ukFsBllFazFnx3Uv9UpzhZ+YNMsAQBPq3k+U3079W1TxsT IwyOCTU7CpJgqclQGxb+sOeOyuL8YCNj6QS5bMiWahh1j2Vn/d0fNHu7mwjwHCNI ztn+yth9+JAMxhzZWn6ee1zrdYAKfLcHrT3ytTG3yAFOFj3g9d3CVYiqlwlBieOp +/tYuoG7i/c7uAeR2GPd =SxWl -----END PGP SIGNATURE----- --5tINJiUS2/Dn5Rhr--