From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Subject: Re: [PATCH] KVM: PPC: Book3S: Add support for H_IPOLL and H_XIRR_X in XICS emulation Date: Tue, 28 May 2013 12:41:42 -0500 Message-ID: <1369762902.18630.2@snotra> References: <20130524014221.GA19310@iris.ozlabs.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; delsp=Yes; format=Flowed Content-Transfer-Encoding: 8BIT Cc: , , , Alexander Graf , Benjamin Herrenschmidt , Gleb Natapov , Marcelo Tosatti To: Paul Mackerras Return-path: In-Reply-To: <20130524014221.GA19310@iris.ozlabs.ibm.com> (from paulus@samba.org on Thu May 23 20:42:21 2013) Content-Disposition: inline Sender: kvm-ppc-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 05/23/2013 08:42:21 PM, Paul Mackerras wrote: > This adds the remaining two hypercalls defined by PAPR for > manipulating > the XICS interrupt controller, H_IPOLL and H_XIRR_X. H_IPOLL returns > information about the priority and pending interrupts for a virtual > cpu, without changing any state. H_XIRR_X is like H_XIRR in that it > reads and acknowledges the highest-priority pending interrupt, but it > also returns the timestamp (timebase register value) from when the > interrupt was first received by the hypervisor. Currently we just > return the current time, since we don't do any software queueing of > virtual interrupts inside the XICS emulation code. > > These hcalls are not currently used by Linux guests, but may be in > future. > > Signed-off-by: Paul Mackerras > --- > Unfortunately I missed these two hcalls in the previous submissions. > It would be good to get this patch into 3.10 so we don't have a > kernel version with these calls missing from the API, in case future > guest kernels want to use them. > > Alex, given you're on vacation at the moment, are you OK with Ben > taking this through his tree? I believe Alex is staying far away from e-mail on his vacation. He's asked me to fill in for him while he's gone. The patch itself seems reasonable (though I don't know much about XICS, and do have one question...), but I'll leave it up to Gleb/Marcelo/Ben if it should go in for 3.10 and via which tree. I understand the desire to not have an incomplete ABI in a released version, but Linus is already grumbling about how much went into rc3, and you say the hcalls aren't currently used... Are they likely to be used in any timeframe in which we'd reasonably care about 3.10? If so, would the effect of not having them implemented be such that it would be worse than not having in-kernel XICS at all? > @@ -787,6 +804,18 @@ int kvmppc_xics_hcall(struct kvm_vcpu *vcpu, u32 > req) > if (!xics || !vcpu->arch.icp) > return H_HARDWARE; > > + /* These requests don't have real-mode implementations at > present */ > + switch (req) { > + case H_XIRR_X: > + res = kvmppc_h_xirr(vcpu); > + kvmppc_set_gpr(vcpu, 4, res); > + kvmppc_set_gpr(vcpu, 5, get_tb()); > + return rc; > + case H_IPOLL: > + rc = kvmppc_h_ipoll(vcpu, kvmppc_get_gpr(vcpu, 4)); > + return rc; > + } > + > /* Check for real mode returning too hard */ > if (xics->real_mode) > return kvmppc_xics_rm_complete(vcpu, req); Could you explain what's going on here relative to kvmppc_xics_rm_complete()? What does "returning too hard" mean, and why must rm_action not be checked for these hcalls? -Scott