From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49355) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZXj9K-0007qh-Tp for qemu-devel@nongnu.org; Fri, 04 Sep 2015 01:02:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZXj9H-0005fT-M5 for qemu-devel@nongnu.org; Fri, 04 Sep 2015 01:02:54 -0400 Date: Fri, 4 Sep 2015 15:02:49 +1000 From: David Gibson Message-ID: <20150904050249.GU6537@voom.redhat.com> References: <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> <55E891C1.5000206@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="p8mP+8RrBGerSNjm" Content-Disposition: inline In-Reply-To: <55E891C1.5000206@linux.vnet.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: Aravinda Prasad Cc: paulus@samba.org, benh@au1.ibm.com, qemu-ppc@nongnu.org, qemu-devel@nongnu.org, Sam Bobroff --p8mP+8RrBGerSNjm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 04, 2015 at 12:00:25AM +0530, Aravinda Prasad wrote: >=20 >=20 > On Thursday 03 September 2015 11:52 AM, 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, eve= n if the > > lock is normally held, I don't see why these particular hcalls couldn't= release > > the lock. I'll look into this. >=20 > I am not sure whether we can release this lock inside an hcall. I need > to check. I don't see any reason that won't work. As long as you only touch most qemu data structures while the lock is held, of course. >=20 > >=20 > >>>> Also, it looks like the vector will need at least one scratch regist= er > >>>> (for the hcall number, if nothing else). Does PAPR specify what SPR= Gs > >>>> the vector can clobber? Obviously it can't be anything the guest > >>>> kernel uses. > >>> > >>> 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. > >> > >> 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. > >>> > >>> 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 > > 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 val= ue and > > check for it later. If it's been clobbered by a kexec, go back to the o= ld > > method. >=20 > "> check for it later" - But does QEMU is informed or get to know when > kexec() is issued? No, but I think Sam is suggesting just rechecking the value when you catch an MC exception. --=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 --p8mP+8RrBGerSNjm Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJV6SX5AAoJEGw4ysog2bOS5nUP/AyQ4QvDmzJWzaxBJO9E6xfw gz7jU2ZxC4hyHbeVNzfSq9e70i3/Qk5b17B2fHL3nKsXcdQRkcHJy+Ud+kjSxQdH zXZ/BfbOqtRA5vw5L3BhF70EJrjTDvoReKV12TYOrP38j1eUpDXcq8BZnjSCo4Le xISY4FykPUPNtUIYU/QAf4nLR6CH63nZBsba6hSPxSZyoOz7ZEZQ8pF7Y2dznY9g +lBeAz0VyooglszGvt8+uHZhHUsm8aUfA+3+r79ZFaPbh7OVTkXF7eOV40MIIpG+ gz3ec+eUCNsWbVh1iOVAzJtV0pYE6PhYYqSWLSqPCqq7IWjP5tz9V3eQ6BP1ZbEf 55WjPlNhdZ5VY+xVQRZM3mDJbtB4t01roEZma9n9hsiBka3WTDn7c8hSXuDaRlsD FmUUnUK6RYhTd/l84c3bPXyrM6bSD9Syh9zl2lKddW+vPRNEfLVve+YjNL718V3/ 19Q6xxONfPnq6MUoZn7e7S4d3n6STJGNy6a4zF5r8svXA2K6NMxyVojq9vM8bbeW LP4LehZiCsvEchzmOSpZ790IfTd9pW0C0YDnE/WRi63cOSRlBIdbR+p5bCMIR2+L 0Ekc2BrRA15bkRxRU2aeoMs1uzQ4t7/2evEMnsOjspGgtGG8vvJ1E094GG+i481T jjIXtG9RkFCqe8bE1MnX =kiDl -----END PGP SIGNATURE----- --p8mP+8RrBGerSNjm--