On Sun, 2020-12-06 at 11:03 +0000, David Woodhouse wrote: > + hva = READ_ONCE(v->kvm->arch.xen.shinfo); > + if (!hva) > + goto out; > + > + offset = v->vcpu_id * sizeof(struct vcpu_info); > + offset += offsetof(struct vcpu_info, time); > + Hm, now there's two days of my life I want back. Looks so innocuous, doesn't it? But v->vcpu_id is very much not what we want there. That's the APIC ID. But we don't want that; we want the ACPI ID (which correlates to the Xen vcpu_id that Xen also puts into CPUID leaf 0x40000004. Or at least I *hope* it correlates since Linux uses the one from CPUID for the boot CPU and the ACPI number for the rest of the CPUS). KVM doesn't *have* the ACPI ID. Not unless we want to go grubbing around in what the VMM put in CPUID leaf 0x40000004... which might be 0x40000204 if Hyper-V is enabled. We don't want to be doing that. So I think we ditch this indexing in the kernel, and require that the VMM explicitly register the vcpu_info address for *every* vCPU, even where the *guest* hasn't explicitly done so, and it ends up being in the shared_info page.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
