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@xxxxxxxxxx> > > > > > > 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.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
