On Wed, Feb 05, 2025, David Woodhouse wrote: > On Wed, 2025-02-05 at 16:18 +0000, David Woodhouse wrote: > > > > > Oh! It doesn't help KVM avoid breaking userspace, but a way for QEMU to avoid a > > > future collision would be to have QEMU start at 0x40000200 when Hyper-V is enabled, > > > but then use KVM_GET_MSR_INDEX_LIST to detect a collision with KVM Hyper-V, e.g. > > > increment the index until an available index is found (with sanity checks and whatnot). > > > > Makes sense. I think that's a third separate patch, yes? > > To be clear, I think I mean a third patch which further restricts > kvm_xen_hvm_config() to disallow indices for which > kvm_is_advertised_msr() returns true? > > We could roll that into your original patch instead, if you prefer. Nah, I like the idea of separate patch. > Q: Should kvm_is_advertised_msr() include the Xen hypercall MSR, if one > is already configured? Life is easier if we answer 'no'... No :-) The idea with kvm_is_advertised_msr() is to ignore accesses to MSRs that don't exist according the to vCPU model, but that KVM advertised to userspace (via KVM_GET_MSR_INDEX_LIST) and so may be saved/restored by a naive/unoptimized userspace. For the Xen MSR, KVM never advertises the MSR, and IIUC, KVM will never treat the MSR as non-existent because defining the MSR brings it into existence.
