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.
I like that it's *different* to the vcpu_id; we should definitely be
testing that case.
I don't quite know why the code was using
vcpu_info[1] in the shinfo before when we were explicitly setting the
address from userspace; I suppose it didn't matter.
Also make some cosmetic fixes to the code for clarity.
Signed-off-by: Paul Durrant <pdurrant@xxxxxxxxxx>
---
Cc: Sean Christopherson <seanjc@xxxxxxxxxx>
Cc: Paolo Bonzini <pbonzini@xxxxxxxxxx>
Cc: David Woodhouse <dwmw2@xxxxxxxxxxxxx>
v2:
- New in this version.
---
.../selftests/kvm/x86_64/xen_shinfo_test.c | 19 +++++++++++++++----
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/tools/testing/selftests/kvm/x86_64/xen_shinfo_test.c b/tools/testing/selftests/kvm/x86_64/xen_shinfo_test.c
index 05898ad9f4d9..49d0c91ee078 100644
--- a/tools/testing/selftests/kvm/x86_64/xen_shinfo_test.c
+++ b/tools/testing/selftests/kvm/x86_64/xen_shinfo_test.c
@@ -38,6 +38,8 @@
#define VCPU_INFO_VADDR (SHINFO_REGION_GVA + 0x40)
#define RUNSTATE_VADDR (SHINFO_REGION_GVA + PAGE_SIZE + PAGE_SIZE - 15)
+#define VCPU_ID 1 /* Must correspond to offset of VCPU_INFO_[V]ADDR */
As well as being a bit clearer in the commit comment as noted above,
let's call this XEN_VCPU_ID ?
With that cleaned up,
Reviewed-by: David Woodhouse <dwmw@xxxxxxxxxxxx>