Re: [GIT PULL] KVM: x86: Changes for 6.15

[Paolo Bonzini]

On Tue, Mar 18, 2025 at 7:03 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote:
> There are two conflicts between the PV clock pull request and the Xen
> pull request.
>
> 1. The Xen branch moves Xen TSC leaf updates to CPUID emulation, and the PV
>    clock branch renames the fields in kvm_vcpu_arch that are used to update
>    the Xen leafs.  After the dust settles, kvm_cpuid() should look like:
>
>                 } else if (IS_ENABLED(CONFIG_KVM_XEN) &&
>                            kvm_xen_is_tsc_leaf(vcpu, function)) {
>                         /*
>                          * Update guest TSC frequency information if necessary.
>                          * Ignore failures, there is no sane value that can be
>                          * provided if KVM can't get the TSC frequency.
>                          */
>                         if (kvm_check_request(KVM_REQ_CLOCK_UPDATE, vcpu))
>                                 kvm_guest_time_update(vcpu);
>
>                         if (index == 1) {
>                                 *ecx = vcpu->arch.pvclock_tsc_mul;
>                                 *edx = vcpu->arch.pvclock_tsc_shift;
>                         } else if (index == 2) {
>                                 *eax = vcpu->arch.hw_tsc_khz;
>                         }
>                 }
>
> 2. The Xen branch moves and renames xen_hvm_config so that its xen.hvm_config,
>    while PV clock branch shuffles use of xen_hvm_config/xen.hvm_config flags.
>    The resulting code in kvm_guest_time_update() should look like:
>
> #ifdef CONFIG_KVM_XEN
>         /*
>          * For Xen guests we may need to override PVCLOCK_TSC_STABLE_BIT as unless
>          * explicitly told to use TSC as its clocksource Xen will not set this bit.
>          * This default behaviour led to bugs in some guest kernels which cause
>          * problems if they observe PVCLOCK_TSC_STABLE_BIT in the pvclock flags.
>          *
>          * Note!  Clear TSC_STABLE only for Xen clocks, i.e. the order matters!
>          */
>         if (ka->xen.hvm_config.flags & KVM_XEN_HVM_CONFIG_PVCLOCK_TSC_UNSTABLE)
>                 hv_clock.flags &= ~PVCLOCK_TSC_STABLE_BIT;
>
>         if (vcpu->xen.vcpu_info_cache.active)
>                 kvm_setup_guest_pvclock(&hv_clock, v, &vcpu->xen.vcpu_info_cache,
>                                         offsetof(struct compat_vcpu_info, time));
>         if (vcpu->xen.vcpu_time_info_cache.active)
>                 kvm_setup_guest_pvclock(&hv_clock, v, &vcpu->xen.vcpu_time_info_cache, 0);
> #endif

Thanks, pulled everything to kvm/queue. I assume you want me to put
the following on top:

* KVM: Drop kvm_arch_sync_events() now that all implementations are nops
* KVM: x86: Fold guts of kvm_arch_sync_events() into kvm_arch_pre_destroy_vm()
* KVM: x86: Unload MMUs during vCPU destruction, not before
* KVM: Assert that a destroyed/freed vCPU is no longer visible
* KVM: x86: Don't load/put vCPU when unloading its MMU during teardown

Paolo