Messages in this thread | | | Subject | Re: [PATCH v2 08/12] KVM: xen: automatically use the vcpu_info embedded in shared_info | From | David Woodhouse <> | Date | Mon, 18 Sep 2023 12:49:42 +0100 |
| |
On Mon, 2023-09-18 at 11:21 +0000, Paul Durrant wrote: > - This is because KVM may > - not be aware of the Xen CPU id which is used as the index into the > - vcpu_info[] array, so may know the correct default location.
Hm, that *was* true at the time of writing, but we did end up teaching KVM about the Xen vcpu_id so that we can handle timers. (We required userspace to provide the APIC ID for all the other event channel stuff, but timer hypercalls come straight from the guest).
But I think the *only* thing we use vcpu->arch.xen.vcpu_id for right now is acceleration of the timer hypercalls that are restricted to the vCPU that they're called from, e.g.:
case VCPUOP_set_singleshot_timer: if (vcpu->arch.xen.vcpu_id != vcpu_id) { *r = -EINVAL;
So it's never mattered much before now if the Xen vcpu_id changes at runtime.
Maybe you now want to invalidate the vcpu_info pfncache for a vCPU if its Xen vcpu_id changes? Or just *forbid* such a change after the shinfo page has been set up? What locking prevents the xen.vcpu_id changing in the middle of your new get_vcpu_info_cache() function? [unhandled content-type:application/pkcs7-signature] | |