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 =20
> 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.
>=20
> These hcalls are not currently used by Linux guests, but may be in
> future.
>=20
> 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.
>=20
> 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 =20
asked me to fill in for him while he's gone.

The patch itself seems reasonable (though I don't know much about XICS, =20
and do have one question...), but I'll leave it up to Gleb/Marcelo/Ben =20
if it should go in for 3.10 and via which tree.  I understand the =20
desire to not have an incomplete ABI in a released version, but Linus =20
is already grumbling about how much went into rc3, and you say the =20
hcalls aren't currently used...  Are they likely to be used in any =20
timeframe in which we'd reasonably care about 3.10?  If so, would the =20
effect of not having them implemented be such that it would be worse =20
than not having in-kernel XICS at all?

> @@ -787,6 +804,18 @@ int kvmppc_xics_hcall(struct kvm_vcpu *vcpu, u32 =20
> req)
>  	if (!xics || !vcpu->arch.icp)
>  		return H_HARDWARE;
>=20
> +	/* These requests don't have real-mode implementations at =20
> present */
> +	switch (req) {
> +	case H_XIRR_X:
> +		res =3D kvmppc_h_xirr(vcpu);
> +		kvmppc_set_gpr(vcpu, 4, res);
> +		kvmppc_set_gpr(vcpu, 5, get_tb());
> +		return rc;
> +	case H_IPOLL:
> +		rc =3D 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 =20
kvmppc_xics_rm_complete()?  What does "returning too hard" mean, and =20
why must rm_action not be checked for these hcalls?

-Scott=