On Tue, May 22, 2012 at 12:46:54AM +0000, Mao, Junjie wrote:
> > > > @@
> > > > > -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.
OK, so in case INVPCID is not available, all instructions which would
otherwise flush PCID-tagged TLB entries in VMX root operation also flush
them in VMX non root operation. Example: CR3 write.
>
> 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?
The point is that other hypervisor might be running as L1 guest.
The problem with enabling PCID for the L2 guest is that it
can share same PCID values with the L1 hypervisor.
However, if the L1 hypervisor enables and configures VPID (given that
the L0 hypervisor emulates and exposes it), there is no problem
in enabling PCID for both L1 and L2 guests because TLB entries
will be differentiated by their VPID values, even if their PCID
values are the same.
So i think that checking whether EPT _and_ VPID are supported
should be a precondition to enable PCID support for guests.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
