diff mbox series

[8/8] KVM: xen: automatically use the vcpu_info embedded in shared_info

Message ID 20230914084946.200043-9-paul@xen.org
State New
Headers
Series KVM: xen: update shared_info and vcpu_info handling |

Commit Message

Paul Durrant Sept. 14, 2023, 8:49 a.m. UTC 
  From: Paul Durrant <pdurrant@amazon.com>

Add a KVM_XEN_HVM_CONFIG_DEFAULT_VCPU_INFO flag so that the VMM knows it
need only set the KVM_XEN_VCPU_ATTR_TYPE_VCPU_INFO attribute in response to
a VCPUOP_register_vcpu_info hypercall, and modify get_vcpu_info_cache()
to pass back a pointer to the shared info pfn cache (and appropriate
offset) for any of the first 32 vCPUs if the attribute has not been set.

Signed-off-by: Paul Durrant <pdurrant@amazon.com>
---
Cc: Sean Christopherson <seanjc@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: x86@kernel.org
---
 arch/x86/kvm/x86.c       |  3 ++-
 arch/x86/kvm/xen.c       | 15 +++++++++++++++
 include/uapi/linux/kvm.h |  1 +
 3 files changed, 18 insertions(+), 1 deletion(-)

Comments

David Woodhouse Sept. 14, 2023, 9:09 a.m. UTC | #1 
On Thu, 2023-09-14 at 08:49 +0000, Paul Durrant wrote:
> From: Paul Durrant <pdurrant@amazon.com>
> 
> Add a KVM_XEN_HVM_CONFIG_DEFAULT_VCPU_INFO flag so that the VMM knows it
> need only set the KVM_XEN_VCPU_ATTR_TYPE_VCPU_INFO attribute in response to
> a VCPUOP_register_vcpu_info hypercall, and modify get_vcpu_info_cache()
> to pass back a pointer to the shared info pfn cache (and appropriate
> offset) for any of the first 32 vCPUs if the attribute has not been set.

Might be simpler just to link this behaviour to the
KVM_XEN_ATTR_TYPE_SHARED_INFO_HVA support? If userspace sets the
shared_info as an HVA, then the default vcpu_info will be used therein.
Paul Durrant Sept. 14, 2023, 9:17 a.m. UTC | #2 
On 14/09/2023 10:09, David Woodhouse wrote:
> On Thu, 2023-09-14 at 08:49 +0000, Paul Durrant wrote:
>> From: Paul Durrant <pdurrant@amazon.com>
>>
>> Add a KVM_XEN_HVM_CONFIG_DEFAULT_VCPU_INFO flag so that the VMM knows it
>> need only set the KVM_XEN_VCPU_ATTR_TYPE_VCPU_INFO attribute in response to
>> a VCPUOP_register_vcpu_info hypercall, and modify get_vcpu_info_cache()
>> to pass back a pointer to the shared info pfn cache (and appropriate
>> offset) for any of the first 32 vCPUs if the attribute has not been set.
> 
> Might be simpler just to link this behaviour to the
> KVM_XEN_ATTR_TYPE_SHARED_INFO_HVA support? If userspace sets the
> shared_info as an HVA, then the default vcpu_info will be used therein.

Well there's no problem in using the default embedded vcpu_info even if 
the guests sets the shared_info via GPA... it still saves the VMM making 
a few ioctls. So do we really want to link the two things?

   Paul
David Woodhouse Sept. 14, 2023, 9:24 a.m. UTC | #3 
On Thu, 2023-09-14 at 11:17 +0200, Paul Durrant wrote:
> On 14/09/2023 10:09, David Woodhouse wrote:
> > On Thu, 2023-09-14 at 08:49 +0000, Paul Durrant wrote:
> > > From: Paul Durrant <pdurrant@amazon.com>
> > > 
> > > Add a KVM_XEN_HVM_CONFIG_DEFAULT_VCPU_INFO flag so that the VMM knows it
> > > need only set the KVM_XEN_VCPU_ATTR_TYPE_VCPU_INFO attribute in response to
> > > a VCPUOP_register_vcpu_info hypercall, and modify get_vcpu_info_cache()
> > > to pass back a pointer to the shared info pfn cache (and appropriate
> > > offset) for any of the first 32 vCPUs if the attribute has not been set.
> > 
> > Might be simpler just to link this behaviour to the
> > KVM_XEN_ATTR_TYPE_SHARED_INFO_HVA support? If userspace sets the
> > shared_info as an HVA, then the default vcpu_info will be used therein.
> 
> Well there's no problem in using the default embedded vcpu_info even if 
> the guests sets the shared_info via GPA... it still saves the VMM making 
> a few ioctls. So do we really want to link the two things?

I'd prefer to avoid the combinatorial explosion in the advertised features.

And ideally we need to allow the VMM to opt *in* to the new behaviour,
although I suppose you could argue that it doesn't make much difference
in this case.
diff mbox series

Patch

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 4cd577d01bc4..cdce8c463a1b 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -4528,7 +4528,8 @@  int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
 		    KVM_XEN_HVM_CONFIG_SHARED_INFO |
 		    KVM_XEN_HVM_CONFIG_EVTCHN_2LEVEL |
 		    KVM_XEN_HVM_CONFIG_EVTCHN_SEND |
-		    KVM_XEN_HVM_CONFIG_SHARED_INFO_HVA;
+		    KVM_XEN_HVM_CONFIG_SHARED_INFO_HVA |
+		    KVM_XEN_HVM_CONFIG_DEFAULT_VCPU_INFO;
 		if (sched_info_on())
 			r |= KVM_XEN_HVM_CONFIG_RUNSTATE |
 			     KVM_XEN_HVM_CONFIG_RUNSTATE_UPDATE_FLAG;
diff --git a/arch/x86/kvm/xen.c b/arch/x86/kvm/xen.c
index 892563fea40f..66050a96ba25 100644
--- a/arch/x86/kvm/xen.c
+++ b/arch/x86/kvm/xen.c
@@ -491,6 +491,21 @@  static void kvm_xen_inject_vcpu_vector(struct kvm_vcpu *v)
 
 struct gfn_to_pfn_cache *get_vcpu_info_cache(struct kvm_vcpu *v, unsigned long *offset)
 {
+	if (!v->arch.xen.vcpu_info_cache.active && v->arch.xen.vcpu_id < MAX_VIRT_CPUS) {
+		struct kvm *kvm = v->kvm;
+
+		if (offset) {
+			if (IS_ENABLED(CONFIG_64BIT) && kvm->arch.xen.long_mode)
+				*offset = offsetof(struct shared_info,
+						   vcpu_info[v->arch.xen.vcpu_id]);
+			else
+				*offset = offsetof(struct compat_shared_info,
+						   vcpu_info[v->arch.xen.vcpu_id]);
+		}
+
+		return &kvm->arch.xen.shinfo_cache;
+	}
+
 	if (offset)
 		*offset = 0;
 
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index d3f371bafad8..480612f73fc2 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -1283,6 +1283,7 @@  struct kvm_x86_mce {
 #define KVM_XEN_HVM_CONFIG_EVTCHN_SEND		(1 << 5)
 #define KVM_XEN_HVM_CONFIG_RUNSTATE_UPDATE_FLAG	(1 << 6)
 #define KVM_XEN_HVM_CONFIG_SHARED_INFO_HVA	(1 << 7)
+#define KVM_XEN_HVM_CONFIG_DEFAULT_VCPU_INFO	(1 << 8)
 
 struct kvm_xen_hvm_config {
 	__u32 flags;