mbox series

[v2,00/12] KVM: xen: update shared_info and vcpu_info handling

Message ID 20230918112148.28855-1-paul@xen.org
Headers
Series KVM: xen: update shared_info and vcpu_info handling |

Message

Paul Durrant Sept. 18, 2023, 11:21 a.m. UTC 
  From: Paul Durrant <pdurrant@amazon.com>

Currently we treat the shared_info page as guest memory and the VMM informs
KVM of its location using a GFN. However it is not guest memory as such;
it's an overlay page. So we pointlessly invalidate and re-cache a mapping
to the *same page* of memory every time the guest requests that shared_info
be mapped into its address space. Let's avoid doing that by modifying the
pfncache code to allow activation using a fixed userspace HVA as well as
a GPA.

Also, if the guest does not hypercall to explicitly set a pointer to a
vcpu_info in its own memory, the default vcpu_info embedded in the
shared_info page should be used. At the moment the VMM has to set up a
pointer to the structure explicitly (again treating it like it's in
guest memory, despite being in an overlay page). Let's also avoid the
need for that. We already have a cached mapping for the shared_info
page so just use that directly by default.

Paul Durrant (12):
  KVM: pfncache: add a map helper function
  KVM: pfncache: add a mark-dirty helper
  KVM: pfncache: add a helper to get the gpa
  KVM: pfncache: base offset check on khva rather than gpa
  KVM: pfncache: allow a cache to be activated with a fixed (userspace)
    HVA
  KVM: xen: allow shared_info to be mapped by fixed HVA
  KVM: xen: prepare for using 'default' vcpu_info
  KVM: xen: automatically use the vcpu_info embedded in shared_info
  KVM: selftests / xen: set KVM_XEN_VCPU_ATTR_TYPE_VCPU_ID
  KVM: selftests / xen: map shared_info using HVA rather than GFN
  KVM: selftests / xen: don't explicitly set the vcpu_info address
  KVM: xen: advertize the KVM_XEN_HVM_CONFIG_SHARED_INFO_HVA capability

 Documentation/virt/kvm/api.rst                |  43 ++++--
 arch/x86/include/asm/kvm_host.h               |   4 +
 arch/x86/kvm/x86.c                            |  17 +--
 arch/x86/kvm/xen.c                            | 121 ++++++++++++----
 arch/x86/kvm/xen.h                            |   6 +-
 include/linux/kvm_host.h                      |  43 ++++++
 include/linux/kvm_types.h                     |   3 +-
 include/uapi/linux/kvm.h                      |   6 +-
 .../selftests/kvm/x86_64/xen_shinfo_test.c    |  79 +++++++++--
 virt/kvm/pfncache.c                           | 129 +++++++++++++-----
 10 files changed, 342 insertions(+), 109 deletions(-)
---
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Sean Christopherson <seanjc@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: x86@kernel.org

Comments

Paul Durrant Sept. 18, 2023, 12:18 p.m. UTC | #1 
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@amazon.com>
>>
>> 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?

> 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.
> 

Yes, I think it was entirely arbitrary.

>> Also make some cosmetic fixes to the code for clarity.
>>
>> Signed-off-by: Paul Durrant <pdurrant@amazon.com>
>> ---
>> Cc: Sean Christopherson <seanjc@google.com>
>> Cc: Paolo Bonzini <pbonzini@redhat.com>
>> Cc: David Woodhouse <dwmw2@infradead.org>
>>
>> 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 ?
>

Ok.


> With that cleaned up,
> 
> Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
> 

Thanks,

   Paul
David Woodhouse Sept. 18, 2023, 1:22 p.m. UTC | #2 
On Mon, 2023-09-18 at 11:21 +0000, Paul Durrant wrote:
> From: Paul Durrant <pdurrant@amazon.com>
> 
> Now that all relevant kernel changes and selftests are in place, enable the
> new capability.
> 
> Signed-off-by: Paul Durrant <pdurrant@amazon.com>

Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>