On Mon, 2023-09-18 at 13:18 +0100, Paul Durrant wrote: > On 18/09/2023 12:59, David Woodhouse wrote: > > On Mon, 2023-09-18 at 11:21 +0000, Paul Durrant wrote: > > > From: Paul Durrant <pdurrant@xxxxxxxxxx> > > > > > > If the capability (KVM_XEN_HVM_CONFIG_EVTCHN_SEND) is present then set > > > the guest's vCPU id to match the chosen vcpu_info offset. > > > > I think from KVM's point of view, the vcpu_id is still zero. As is the > > vcpu_idx. What you're setting is the *Xen* vcpu_id. > > Ok. I'll clarify the terminology; and I'll need to set it before the > shinfo as noted on another thread. > > > > > I like that it's *different* to the vcpu_id; we should definitely be > > testing that case. > > How so? > Well, imagine you'd not got the kernel's get_vcpu_info_cache() right, and you accidentally used v->vcpu_id instead of v->arch.xen.vcpu_id. An easy mistake to make, right? If you had made that mistake (you didn't; I checked), and if those numbers had happened to be equal in this test... then this test wouldn't have shown it.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
