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: Tue, 16 Jul 2013 18:37:46 -0500 Message-ID: <1374017866.8183.347@snotra> References: <1374017200.8183.346@snotra> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; delsp=Yes; format=Flowed Content-Transfer-Encoding: 8BIT Cc: Alexander Graf , Bhushan Bharat-R65777 , "kvm@vger.kernel.org" , "kvm-ppc@vger.kernel.org" , Wood Scott-B07421 , Yoder Stuart-B08248 To: Scott Wood Return-path: In-Reply-To: <1374017200.8183.346@snotra> (from scottwood@freescale.com on Tue Jul 16 18:26:40 2013) Content-Disposition: inline Sender: kvm-ppc-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 07/16/2013 06:26:40 PM, Scott Wood wrote: > On 07/16/2013 06:21:51 PM, Alexander Graf wrote: >> >> On 16.07.2013, at 00:23, Scott Wood wrote: >> >> > Still, I'm not sure what sort of error you're thinking of. If the >> guest didn't support the hcall mechanism we would have returned from >> the function by that point. In fact, seeing kvm,has-reset on a >> different hypervisor ought to mean that that hypervisor is emulating >> KVM in this particular respect. >> >> Imagine we're running on KVM with this reset hcall support. Now if >> the guest has CONFIG_EPAPR_PARAVIRT enabled but CONFIG_KVM_GUEST >> disabled, we would patch the callback, but kvm_hypercall0() would be >> implemented as a nop. > > Ugh -- that should be renamed epapr_hypercall and moved to > epapr_paravirt.c. Or rather, kvm_hypercall() should become epapr_hypercall() in epapr_paravirt.c -- there's nothing KVM-specific about it. kvm_hypercall0() and friends could become epapr_hypercall0() in epapr_hcalls.h, with the KVM_HCALL_TOKEN() moved to the caller. Or they could stay as they are but depend on CONFIG_EPAPR_PARAVIRT rather than CONFIG_KVM_GUEST -- there's no real dependency on the rest of the KVM guest code. -Scott