Re: [PATCH v2 1/6] KVM: x86: Add dedicated storage for guest RIP

[Xiaoyao Li <xiaoyao.li@intel.com>]

On 4/10/2026 6:42 AM, Sean Christopherson wrote:
> Add kvm_vcpu_arch.rip to track guest RIP instead of including it in the
> generic regs[] array.  Decoupling RIP from regs[] will allow using a
> *completely* arbitrary index for RIP, as opposed to the mostly-arbitrary
> index that is currently used.  That in turn will allow using indices
> 16-31 to track R16-R31 that are coming with APX.

Even leave RIP in regs[], what is the problem by just allocating the 
index 16-31 to R16-R31 and making RIP the index 32? (I think I need go 
read the APX discussion to better understand the reason)

> Note, although RIP can used for addressing, it does NOT have an
                          ^
missing a 'be'

> architecturally defined index, and so can't be reached via flows like
> get_vmx_mem_address() where KVM "blindly" reads a general purpose register
> given the SIB information reported by hardware.  For RIP-relative
> addressing, hardware reports the full "offset" in vmcs.EXIT_QUALIFICATION.
> 
> Note #2, keep the available/dirty tracking as RSP is context switched

s/RSP/RIP

> through the VMCS, i.e. needs to be cached for VMX.
> 
> Opportunistically rename NR_VCPU_REGS to NR_VCPU_GENERAL_PURPOSE_REGS to
> better capture what it tracks, and so that KVM can slot in R16-R13 without

s/R16-R13/R16-R31

> running into weirdness where KVM's definition of "EXREG" doesn't line up
> with APX's definition of "extended reg".
> 
> No functional change intended.
>