Re: [PATCH] KVM: PPC: Book3S: Add support for H_IPOLL and H_XIRR_X in XICS emulation

[Scott Wood <scottwood@freescale.com>]

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 <paulus@samba.org>
> ---
> 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