On 18/09/2023 12:49, David Woodhouse wrote:
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?
That's a good point; the vcpu lock itself won't be enough. I think
forbidding a change of id while a shared_info page is in place is
probably the most sensible semantic.
Paul
