From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38787) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZXZIG-0000gQ-OI for qemu-devel@nongnu.org; Thu, 03 Sep 2015 14:31:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZXZIB-0004x0-OW for qemu-devel@nongnu.org; Thu, 03 Sep 2015 14:31:28 -0400 Received: from e39.co.us.ibm.com ([32.97.110.160]:35900) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZXZIB-0004wo-IN for qemu-devel@nongnu.org; Thu, 03 Sep 2015 14:31:23 -0400 Received: from /spool/local by e39.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 3 Sep 2015 12:31:22 -0600 Message-ID: <55E891C1.5000206@linux.vnet.ibm.com> Date: Fri, 04 Sep 2015 00:00:25 +0530 From: Aravinda Prasad MIME-Version: 1.0 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> <20150903062222.GA16268@tungsten.ozlabs.ibm.com> In-Reply-To: <20150903062222.GA16268@tungsten.ozlabs.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: paulus@samba.org, benh@au1.ibm.com, qemu-ppc@nongnu.org, qemu-devel@nongnu.org, David Gibson On Thursday 03 September 2015 11:52 AM, Sam Bobroff wrote: > 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. I am not sure whether we can release this lock inside an hcall. I need to check. > >>>> 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. "> check for it later" - But does QEMU is informed or get to know when kexec() is issued? Regards, Aravinda > > Sam. > -- Regards, Aravinda