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