From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33538) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZXNw1-00062C-L3 for qemu-devel@nongnu.org; Thu, 03 Sep 2015 02:23:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZXNvy-0003rd-HP for qemu-devel@nongnu.org; Thu, 03 Sep 2015 02:23:45 -0400 Received: from e23smtp08.au.ibm.com ([202.81.31.141]:32820) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZXNvx-0003rN-Uu for qemu-devel@nongnu.org; Thu, 03 Sep 2015 02:23:42 -0400 Received: from /spool/local by e23smtp08.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 3 Sep 2015 16:23:39 +1000 Date: Thu, 3 Sep 2015 16:22:22 +1000 From: Sam Bobroff Message-ID: <20150903062222.GA16268@tungsten.ozlabs.ibm.com> References: <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> <20150903050521.GK6537@voom.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150903050521.GK6537@voom.redhat.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: David Gibson Cc: Aravinda Prasad , benh@au1.ibm.com, qemu-ppc@nongnu.org, qemu-devel@nongnu.org, paulus@samba.org On Thu, Sep 03, 2015 at 03:05:21PM +1000, David Gibson wrote: [snip] > Hm.. so why can't the hypervisor code do the retrying? Aravinda replied to this earlier in the thread: "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." 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 release the lock. I'll look into this. > > > 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. > > > > 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. 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. Sam.