From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Subject: Re: [PATCH 5/5] powerpc: using reset hcall when kvm,has-reset Date: Mon, 15 Jul 2013 15:52:47 -0500 Message-ID: <1373921567.8183.316@snotra> References: <1373886679-19581-1-git-send-email-Bharat.Bhushan@freescale.com> <1373886679-19581-6-git-send-email-Bharat.Bhushan@freescale.com> <7A2C8450-46FF-4160-B045-F2A3F8F3B8B7@suse.de> <6A3DF150A5B70D4F9B66A25E3F7C888D070D27C7@039-SN2MPN1-013.039d.mgd> <9F4ADF63-D183-4C39-9959-087AE64592DA@suse.de> <6A3DF150A5B70D4F9B66A25E3F7C888D070D2883@039-SN2MPN1-013.039d.mgd.msft.net> <1373912503.8183.311@snotra> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; delsp=Yes; format=Flowed Content-Transfer-Encoding: 8BIT Cc: Bhushan Bharat-R65777 , "kvm@vger.kernel.org" , "kvm-ppc@vger.kernel.org" , Wood Scott-B07421 , Yoder Stuart-B08248 To: Alexander Graf Return-path: In-Reply-To: (from agraf@suse.de on Mon Jul 15 15:28:46 2013) Content-Disposition: inline Sender: kvm-ppc-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 07/15/2013 03:28:46 PM, Alexander Graf wrote: > > On 15.07.2013, at 20:21, Scott Wood wrote: > > > On 07/15/2013 10:16:41 AM, Bhushan Bharat-R65777 wrote: > >> > >>> + printk("error: system reset returned with error %ld\n", > ret); > >> > >> > >> > >> So we should fall back to the normal reset handler here. > >> > > > >> > > Do you mean return normally from here, no BUG() etc? > >> > > >> > If we guard the patching against everything, we can treat a > broken hcall as BUG. > >> > However, if we don't we want to fall back to the normal guts > based reset. > >> Will let Scott comment on this? > >> But ppc_md.restart can point to only one handler and during > paravirt patching we changed this to new handler. So we cannot jump > back to guts type handler > > > > I don't think it's worth implementing a fall-back scheme -- if KVM > advertises that the reset hcall exists, then it had better exist. > > If we also check for kvm_para_available() I agree. Otherwise QEMU > might advertise the reset hcall, but the guest kernel may not > implement KVM hypercalls. In that case the device tree check will > succeed, but the actual hypercall will not. Wouldn't that be a bug in QEMU? Or in KVM for exposing the hcall capability without implementing them? Not that I have anything against checking kvm_para_available()... though that (or its functional equivalent that returns a pointer to the node) should really be a prerequisite for even being able to interpret KVM-specific properties in the hypervisor node. -Scott