> > > @@
> > > > -1711,6 +1717,22 @@ static bool vmx_rdtscp_supported(void)
> > > > return cpu_has_vmx_rdtscp();
> > > > }
> > > >
> > > > +static bool vmx_pcid_supported(void) {
> > > > + /*
> > > > + * This function is only for determining whether to expose PCID bit
> > > > + * in KVM_GET_SUPPORTED_CPUID ioctl. The HYPERVISOR bit is
> used to
> > > > + * prevent guest hypervisors from exposing it as PCID is currently
> > > > + * not supported on L2 guests.
> > > > + */
> > > > + return (boot_cpu_has(X86_FEATURE_PCID)
> && !cpu_has_hypervisor);
> > > > +}
> > >
> > > This is not necessary: KVM will not expose
> > > secondary-exec-enable-invpcid support to the L1 guest, and so L1
> > > guest will not attempt to expose PCID support to L2 guest.
> > >
> >
> > On a platform with PCID but without INVPCID, PCID will be exposed when
> both L1 and L2 are running with '-cpu host' if the '!cpu_has_hypervisor' check
> doesn't exist. Lacking of INVPCID doesn't prevent PCID from being exposed.
>
> Is it correct to expose PCID when INVPCID-EXITING is not supported ?
>
> That is, if INVPCID-EXITING is not supported by VMX, it should not expose PCID
> (because INVPCID is not emulated, and as you mentioned emulating it would
> be slow), no?
Though PCID brings little performance gain without INVPCID, it doesn't prevent PCID from being exposed as these two features are controlled separately now. And there do exist platforms which has PCID but doesn't have INVPCID. It's up to the user to decide whether to use PCID when INVPCID is not present.
The previous patch regards PCID and INVPCID as a whole because qemu doesn't support cpuid leaf 7 configuration at present. This is not the case in this version.
>
> The problem with cpu_has_hypervisor check is that its Linux specific.
> Any solution should also take into account other OSes running as L1 guest and
> virtualizing L2 guest.
Is there any other way, which applies to all host hypervisors, to know if kvm is running as a guest hypervisor?
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
