Re: [PATCH] KVM: x86/hyperv: Explicitly reject VP Assist Page reads if cache was clobbered

[Sean Christopherson]

On Thu, Oct 22, 2026, Vitaly Kuznetsov wrote:
> Sean Christopherson <seanjc@xxxxxxxxxx> writes:
> 
> > Don't try to read the VP Assist Page if the shared PV EOI cache has been
> > reconfigured via KVM's actual PV EOI MSR, as trying to read 624 bytes of
> > info when the cache is setup for only 1 byte will trip the sanity check
> > WARN in kvm_read_guest_offset_cached().  Ideally, KVM wouldn't use shared
> > state to track the VP Assist Page, but in practice no sane guest enables
> > both KVM's PV EOI and Hyper-V's Assist Page at different addresses, i.e.
> > not allowing both to co-exist independently is "fine".
> >
> > Fixes: b63cf42fd1d8 ("kvm/x86: implement hv EOI assist")
> > Cc: stable@xxxxxxxxxxxxxxx
> > Reported-by: Amirmohammad Eftekhar <amirmohammad.eftekhar@xxxxxxxx>
> > Closes: https://lore.kernel.org/all/20261017093016.32348-7-amirmohammad.eftekhar@xxxxxxxx
> > Signed-off-by: Sean Christopherson <seanjc@xxxxxxxxxx>
> 
> Reviewed-by: Vitaly Kuznetsov <vkuznets@xxxxxxxxxx>
> 
> (I am, however, thinking it would be better in the long term to either
> separate KVM PV / Hyper-V PV state here or even consider a 'big
> hammer' and make these two (+Xen?) mutually exclusive for all PV
> features.)

I generally agree, the problem is that any changes could break guests.  For
whatever reason, kvm_lapic_set_pv_eoi() very deliberately allows the two features
to overlay.  I.e. while it seems absurd, in theory a guest could rely on being to
use the two features simultaneously.

OMG, it's your fault!  LOL.  (Obviously not actually your fault since you were
just trying to clean up the mess created by the initial implementation).

  Author:     Vitaly Kuznetsov <vkuznets@xxxxxxxxxx>
  AuthorDate: Tue Oct 16 18:50:06 2018 +0200
  Commit:     Paolo Bonzini <pbonzini@xxxxxxxxxx>
  CommitDate: Wed Oct 17 00:30:17 2018 +0200

    x86/kvm/lapic: preserve gfn_to_hva_cache len on cache reinit
    
    vcpu->arch.pv_eoi is accessible through both HV_X64_MSR_VP_ASSIST_PAGE and
    MSR_KVM_PV_EOI_EN so on migration userspace may try to restore them in any
    order. Values match, however, kvm_lapic_enable_pv_eoi() uses different
    length: for Hyper-V case it's the whole struct hv_vp_assist_page, for KVM
    native case it is 8. In case we restore KVM-native MSR last cache will
    be reinitialized with len=8 so trying to access VP assist page beyond
    8 bytes with kvm_read_guest_cached() will fail.
    
    Check if we re-initializing cache for the same address and preserve length
    in case it was greater.
    
    Signed-off-by: Vitaly Kuznetsov <vkuznets@xxxxxxxxxx>
    Cc: stable@xxxxxxxxxxxxxxx
    Signed-off-by: Paolo Bonzini <pbonzini@xxxxxxxxxx>

So yeah, it definitely seems like we can separate the two since odds are very good
the only reason they "co-exist" is pbecause KVM tricked userspace into effectively
saving/restoring garbage via MSR_KVM_PV_EOI_EN.