Re: [PATCH v2 02/16] KVM: x86: Refactor GPR accessors to differentiate register access types

[Sean Christopherson]

On Mon, Jan 12, 2026, Chang S. Bae wrote:
> Refactor the GPR accessors to introduce internal helpers to distinguish
> between legacy and extended GPRs. Add CONFIG_KVM_APX to selectively
> enable EGPR support.

Why?  If we really want to make this code efficient, use static calls to wire
things up if and only if APX is fully supported.

> +#ifdef CONFIG_KVM_APX
> +static unsigned long kvm_read_egpr(int reg)
> +{
> +	return 0;
> +}
> +
> +static void kvm_write_egpr(int reg, unsigned long data)
> +{
> +}
> +
> +unsigned long kvm_gpr_read_raw(struct kvm_vcpu *vcpu, int reg)
> +{
> +	switch (reg) {
> +	case VCPU_REGS_RAX ... VCPU_REGS_R15:
> +		return kvm_register_read_raw(vcpu, reg);
> +	case VCPU_XREG_R16 ... VCPU_XREG_R31:
> +		return kvm_read_egpr(reg);
> +	default:
> +		WARN_ON_ONCE(1);
> +	}
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_gpr_read_raw);
> +
> +void kvm_gpr_write_raw(struct kvm_vcpu *vcpu, int reg, unsigned long val)
> +{
> +	switch (reg) {
> +	case VCPU_REGS_RAX ... VCPU_REGS_R15:
> +		kvm_register_write_raw(vcpu, reg, val);
> +		break;
> +	case VCPU_XREG_R16 ... VCPU_XREG_R31:
> +		kvm_write_egpr(reg, val);
> +		break;
> +	default:
> +		WARN_ON_ONCE(1);
> +	}
> +}
> +EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_gpr_write_raw);
> +#endif

Has anyone done analysis to determine if KVM's currently inlining of
kvm_register_read() and kvm_register_write() is actually a net positive?  I.e.
can we just cut over to non-inline functions with static calls?