From: Paul Durrant <[email protected]>
If the vCPU id is set and the shared_info is mapped using HVA then we can
infer that KVM has the ability to use a default vcpu_info mapping. Hence
we can stop setting the address of the vcpu_info structure.
Signed-off-by: Paul Durrant <[email protected]>
---
Cc: Sean Christopherson <[email protected]>
Cc: Paolo Bonzini <[email protected]>
Cc: David Woodhouse <[email protected]>
v2:
- New in this version.
---
tools/testing/selftests/kvm/x86_64/xen_shinfo_test.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 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 fa829d6e0848..d1c88deec0b2 100644
--- a/tools/testing/selftests/kvm/x86_64/xen_shinfo_test.c
+++ b/tools/testing/selftests/kvm/x86_64/xen_shinfo_test.c
@@ -550,11 +550,13 @@ int main(int argc, char *argv[])
vcpu_ioctl(vcpu, KVM_XEN_VCPU_SET_ATTR, &vid);
}
- struct kvm_xen_vcpu_attr vi = {
- .type = KVM_XEN_VCPU_ATTR_TYPE_VCPU_INFO,
- .u.gpa = VCPU_INFO_ADDR,
- };
- vcpu_ioctl(vcpu, KVM_XEN_VCPU_SET_ATTR, &vi);
+ if (!has_vcpu_id || !has_shinfo_hva) {
+ struct kvm_xen_vcpu_attr vi = {
+ .type = KVM_XEN_VCPU_ATTR_TYPE_VCPU_INFO,
+ .u.gpa = VCPU_INFO_ADDR,
+ };
+ vcpu_ioctl(vcpu, KVM_XEN_VCPU_SET_ATTR, &vi);
+ }
struct kvm_xen_vcpu_attr pvclock = {
.type = KVM_XEN_VCPU_ATTR_TYPE_VCPU_TIME_INFO,
--
2.39.2
On 18/09/2023 14:21, David Woodhouse wrote:
> On Mon, 2023-09-18 at 11:21 +0000, Paul Durrant wrote:
>> From: Paul Durrant <[email protected]>
>>
>> If the vCPU id is set and the shared_info is mapped using HVA then we can
>> infer that KVM has the ability to use a default vcpu_info mapping. Hence
>> we can stop setting the address of the vcpu_info structure.
>
> Again that means we're not *testing* it any more when the test is run
> on newer kernels. Can we perhaps set it explicitly, after *half* the
> tests are done? Maybe to a *different* address than the default which
> is derived from the Xen vcpu_id? And check that the memcpy works right
> when we do?
>
Ok. The VMM is currently responsible for that memcpy. Are you suggesting
we push that into KVM too?
Paul
On Mon, 2023-09-18 at 11:21 +0000, Paul Durrant wrote:
> From: Paul Durrant <[email protected]>
>
> If the vCPU id is set and the shared_info is mapped using HVA then we can
> infer that KVM has the ability to use a default vcpu_info mapping. Hence
> we can stop setting the address of the vcpu_info structure.
Again that means we're not *testing* it any more when the test is run
on newer kernels. Can we perhaps set it explicitly, after *half* the
tests are done? Maybe to a *different* address than the default which
is derived from the Xen vcpu_id? And check that the memcpy works right
when we do?