[BUG] KVM: x86: Hyper-V VP-assist page reuses the KVM PV-EOI gfn_to_hva_cache, so enabling both WARNs and fails KVM_RUN

[Amirmohammad Eftekhar]

Hi,

Reporting a guest self-DoS (correctness/robustness; not memory-safety, not
guest->host).

The Hyper-V VP-assist page and KVM's PV-EOI feature share a single
gfn_to_hva_cache, vcpu->arch.pv_eoi.data:

 - Writing HV_X64_MSR_VP_ASSIST_PAGE arms the cache for the VP-assist page via
   kvm_lapic_set_pv_eoi(vcpu, gfn_to_gpa(gfn) | KVM_MSR_ENABLED,
   sizeof(struct hv_vp_assist_page))   /* hyperv.c ~1600 */
 - kvm_hv_get_assist_page() then reads it back with that same cache and the
   VP-assist length:
   kvm_read_guest_cached(kvm, &vcpu->arch.pv_eoi.data,
                         &hv_vcpu->vp_assist_page,
                         sizeof(struct hv_vp_assist_page))  /* hyperv.c ~952 */

pv_eoi.data is the one gfn_to_hva_cache shared between the two features. A guest
that has VP-assist enabled and then writes MSR_KVM_PV_EOI_EN (a different GPA,
len 1) re-initializes pv_eoi.data for the 1-byte PV-EOI object while VP-assist
stays enabled. The next kvm_hv_get_assist_page() then does a cached read of
sizeof(struct hv_vp_assist_page) against a cache set up for len 1 -> the
length/GPA mismatch trips the cache and KVM fails the read, surfacing as a WARN
and a failed KVM_RUN for a guest that did nothing architecturally illegal (the
two features are independent and both legitimately enableable).

Impact / class
--------------
Guest self-DoS (the guest breaks its own vCPU); low severity, no host memory
safety or cross-VM effect. Reported because "enable two unrelated, individually
valid features -> WARN + failed KVM_RUN" is a robustness bug.

Suggested direction
-------------------
Give the Hyper-V VP-assist page its own gfn_to_hva_cache instead of borrowing
vcpu->arch.pv_eoi.data, so the two features cannot clobber each other's cache.
Happy to send a patch once you confirm that's the preferred fix.

Read-confirmed against kvm-x86/next (tip of 2026-10-13); present in mainline
v7.3-rc6.

Thanks,
Amirmohammad