On Wed, 2022-12-14 at 10:28 +0000, Paul Durrant wrote: > On 13/12/2022 00:13, David Woodhouse wrote: > > On Mon, 2022-12-12 at 14:58 +0000, Paul Durrant wrote: > > > On 09/12/2022 09:56, David Woodhouse wrote: > > > > > > > > @@ -1811,6 +1811,9 @@ int kvm_arch_init_vcpu(CPUState *cs) > > > > has_msr_hv_hypercall = true; > > > > } > > > > > > > > + env->xen_vcpu_info_gpa = UINT64_MAX; > > > > + env->xen_vcpu_info_default_gpa = UINT64_MAX; > > > > > > > > > There was an INVALID_GPA definition for shared info. Looks like we > > > could use it here too. > > > > There was, and I started trying to use it, but it fell foul of the "is > > this going to live in target/ or hw/ and who can include what from > > where?" and I decided to just use UINT64_MAX for now and keep typing. > > > > That will work out in the end, I'm sure. > > Hopefully > https://lore.kernel.org/lkml/20221209023622.274715-1-yu.c.zh...@linux.intel.com/ > > will help.
Those are kernel-internal; not in uapi headers. Although maybe they *should* be uapi, at least for the KVM/Xen support because they are actually part of the userspace ABI. The kernel returns GFN_INVALID when queried about the shared info page if it isn't set, or GPA_INVALID when queried about vcpu_info etc. (Those are the same numerically but semantically subtly different, and it hurts my brain that GFN_INVALID != GPA_INVALID >> PAGE_SHIFT.) Userspace can also *set* those fields to Gxx_INVALID. Unlike the Xen APIs which don't allow them to be turned off, we implement SHUTDOWN_soft_reset in the userspace VMM so it needs to be able to turn the shinfo areas off.
smime.p7s
Description: S/MIME cryptographic signature
