On 11/01/21 20:57, David Woodhouse wrote:
+
+KVM_XEN_ATTR_TYPE_LONG_MODE
+ Sets the ABI mode of the VM to 32-bit or 64-bit (long mode). This
+ determines the layout of the shared info pages exposed to the VM.
+
+KVM_XEN_ATTR_TYPE_SHARED_INFO
+ Sets the guest physical frame number at which the Xen "shared info"
+ page resides. Note that although Xen places vcpu_info for the first
+ 32 vCPUs in the shared_info page, KVM does not automatically do so
+ and requires that KVM_XEN_ATTR_TYPE_VCPU_INFO be used explicitly
+ even when the vcpu_info for a given vCPU resides at the "default"
+ location in the shared_info page. This is because KVM is not aware
+ of the Xen CPU id which is used as the index into the vcpu_info[]
+ array, so cannot know the correct default location.
+
+KVM_XEN_ATTR_TYPE_VCPU_INFO
+ Sets the guest physical address of the vcpu_info for a given vCPU.
+
+KVM_XEN_ATTR_TYPE_VCPU_TIME_INFO
+ Sets the guest physical address of an additional pvclock structure
+ for a given vCPU. This is typically used for guest vsyscall support.
+
+KVM_XEN_ATTR_TYPE_VCPU_RUNSTATE
+ Sets the guest physical address of the vcpu_runstate_info for a given
+ vCPU. This is how a Xen guest tracks CPU state such as steal time.
+
My only qualm is really that the userspace API is really ugly.
Can you just have both a VM and a VCPU ioctl (so no vcpu_id to pass!),
add a generous padding to the struct, and just get everything out with a
single ioctl without having to pass in a type?
Paolo
