On Mon, May 14, 2012, Marcelo Tosatti wrote about "Re: [PATCH v2] KVM: x86: Implement PCID/INVPCID for guests with EPT":
> > + * Enable INVPCID for non-ept guests may cause performance regression,
> > + * and without INVPCID, PCID has little benefits. So disable them all
> > + * for non-ept guests.
> > + *
> > + * PCID is not supported for nested guests yet.
> > + */
> > + return enable_ept && (boot_cpu_data.x86_capability[4] & bit(X86_FEATURE_PCID)) && !cpu_has_hypervisor;
> > +}
>
> The comment Avi made was regarding running a nested guest, not running
> _as_ a nested guest (which is what cpu_has_hypervisor is about).
>
> You can disable INVPCID exec control (which #UDs), if its in Level-2
> guest mode (see if_guest_mode()), and restore the Level-1 value when
> leaving nested mode.
I also don't understand the !cpu_has_hypervisor thing. Regarding
running a nested guest - the code in prepare_vmcs02() sets (among other
things) secondary exec controls used to run the L2 guest. It mostly
"or"s the bits requested by KVM (L0) and the guest (L1). So:
1. If you think L0 mustn't run L2 with a certain bit, despite running L1
with it (I didn't follow the reasoning why this is the case), you can
specificially turn it off in that function (like we already do for
SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES).
2. The other thing that could theoretically happen is that L1 will ask
to turn on this bit for L2 (I think this is the case you wanted to
avoid). This *won't* happen, because we tell L1 via MSR which bits
it is allowed to set on secondary controls (see
nested_vmx_secondary_ctls_high), and currently this only includes
SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES and
SECONDARY_EXEC_ENABLE_EPT (the latter only for nested EPT), and enforce
that L1 doesn't try to turn on more bits.
--
Nadav Har'El | Tuesday, May 15 2012,
nyh@xxxxxxxxxxxxxxxxxxx |-----------------------------------------
Phone +972-523-790466, ICQ 13349191 |A bird in the hand is safer than one
http://nadav.harel.org.il |overhead.
--
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
