On Tue, Oct 29, 2019 at 04:52:08PM -0700, Edgecombe, Rick P wrote: > On Tue, 2019-10-29 at 16:33 -0700, Kees Cook wrote: > > On Thu, Oct 03, 2019 at 02:23:56PM -0700, Rick Edgecombe wrote: > > > Add a new CPUID leaf to hold the contents of CPUID 0x40000030 EAX to > > > detect KVM defined generic VMM features. > > > > > > The leaf was proposed to allow KVM to communicate features that are > > > defined by KVM, but available for any VMM to implement. This doesn't necessarily work the way you intend, KVM's base CPUID isn't guaranteed to be 0x40000000. E.g. KVM supports advertising itself as HyperV *and* KVM, in which case KVM's CPUID base will be 0x40000100. I think you're better off just making this a standard KVM CPUID feature. If a different hypervisor wants to reuse guest support as is, it can advertise KVM support at a lower priority. Note, querying guest CPUID isn't straightforward in either case. But, KVM doesn't support disabling its other CPUID-base paravirt features, e.g. KVM emulates the kvm_clock MSRs regardless of what userspace advertises to the guest. Depending on what changes are required in KVM's MMU, this may also need to be a KVM-wide feature, i.e. controlled via a module param. > > > Add cpu_feature_enabled() support for features in this leaf (KVM XO), and > > > a pgtable_kvmxo_enabled() helper similar to pgtable_l5_enabled() so that > > > pgtable_kvmxo_enabled() can be used in early code that includes > > > arch/x86/include/asm/sparsemem.h. > > > > > > Lastly, in head64.c detect and this feature and perform necessary > > > adjustments to physical_mask. > > > > Can this be exposed to /proc/cpuinfo so a guest userspace can determine > > if this feature is enabled? > > > > -Kees > > Is there a good place to expose the information that the PROT_EXEC and > !PROT_READ combo creates execute-only memory? This way apps can check one place > for the support and not worry about the implementation whether it's this, x86 > pkeys, arm or other. I don't think so? Assuming there's no common method, it can be displayed in /proc/cpuinfo by adding a synthetic bit, e.g. in Linux-defined word 8 (virtualization) instead of a dedicated word. The bit can then be set if the features exists and is enabled (by the guest). I'd also name the feature EXEC_ONLY. XO is unnecessarily terse IMO, and including "KVM" in the name may be misconstrued as a host KVM feature and will be flat out wrong if hardware ever supports XO natively.
