On Tue, Aug 14, 2018 at 12:30 PM Jim Mattson <jmattson@xxxxxxxxxx> wrote: > > On Tue, Aug 14, 2018 at 11:52 AM, Konrad Rzeszutek Wilk > <konrad.wilk@xxxxxxxxxx> wrote: > > On Tue, Aug 14, 2018 at 10:30:48AM -0700, Jim Mattson wrote: > >> Expose IA32_FLUSH_CMD to the guest if the guest CPUID enumerates > >> support for this MSR. As with IA32_PRED_CMD, permission for > >> unintercepted writes to this MSR will be granted to the guest after > >> the first non-zero write. > > > > I can't seem to find the Intel docs (even thought all the pages > > are all set), but my understanding is that the ARCH_CAPABILITIES Bit(3) > > would suffice. That is it says that for nested OSes you shouldn't > > use the IA32_FLUSH_CMD? > > If the L0 hypervisor performs an L1D$ flush on every emulated VM-entry > from L1 to L2 (which kvm may or may not do, depending on its > configuration) and if it reports that in > IA32_ARCH_CAPABILITIES.SKIP_L1DFL_VMENTRY[bit 3], then it would be > pointless for the L1 hypervisor to use IA32_FLUSH_CMD on VM-entry to > L2. However, (a) the L0 hypervisor may not perform an L1D$ flush on > every emulated VM-entry from L1 to L2, and (b) there may be other > reasons that an L1 guest (hypervisor or not) wants to perform an L1D$ > flush using IA32_FLUSH_CMD. It is more forward-thinking to provide > this capability than it is not to. And it's all configurable from > userspace, so if you don't want it, you don't have to enable it. Ping.
