Lines Matching refs:L1D

97    share the L1 Data Cache (L1D) is important for this. As the flaw allows
98    only to attack data which is present in L1D, a malicious guest running
99    on one Hyperthread can attack the data which is brought into the L1D by
145   - L1D Flush mode:
148     'L1D vulnerable'		      L1D flushing is disabled
150     'L1D conditional cache flushes'   L1D flush is conditionally enabled
152     'L1D cache flushes'		      L1D flush is unconditionally enabled
170 1. L1D flush on VMENTER
173    To make sure that a guest cannot attack data which is present in the L1D
174    the hypervisor flushes the L1D before entering the guest.
176    Flushing the L1D evicts not only the data which should not be accessed
178    data. Flushing the L1D has a performance impact as the processor has to
179    bring the flushed guest data back into the L1D. Depending on the
187    The kernel provides two L1D flush modes:
191    The conditional mode avoids L1D flushing after VMEXITs which execute
197    Unconditional mode flushes L1D on all VMENTER invocations and provides
202    The general recommendation is to enable L1D flush on VMENTER. The kernel
205    **Note**, that L1D flush does not prevent the SMT problem because the
206    sibling thread will also bring back its data into the L1D which makes it
209    L1D flush can be controlled by the administrator via the kernel command
345    line parameter in combination with L1D flush control. See
373 		the hypervisors, i.e. unconditional L1D flushing
375 		SMT control and L1D flush control via the sysfs interface
378 		insecure configuration, i.e. SMT enabled or L1D flush
381   full,force	Same as 'full', but disables SMT and L1D flush runtime
386 		mitigation, i.e. conditional L1D flushing
388 		SMT control and L1D flush control via the sysfs interface
391 		insecure configuration, i.e. SMT enabled or L1D flush
395 		i.e. conditional L1D flushing.
397 		SMT control and L1D flush control via the sysfs interface
400 		insecure configuration, i.e. SMT enabled or L1D flush
413 The default is 'flush'. For details about L1D flushing see :ref:`l1d_flush`.
421 The KVM hypervisor mitigation mechanism, flushing the L1D cache when
428   always	L1D cache flush on every VMENTER.
430   cond		Flush L1D on VMENTER only when the code between VMEXIT and
466    To avoid the overhead of the default L1D flushing on VMENTER the
479   the kernel, it's only required to enforce L1D flushing on VMENTER.
481   Conditional L1D flushing is the default behaviour and can be tuned. See
488   the system is fully protected. SMT can stay enabled and L1D flushing on
499   - L1D flushing on VMENTER:
501     L1D flushing on VMENTER is the minimal protection requirement, but it
504     Conditional L1D flushing is the default behaviour and can be tuned. See
533     Disabling SMT and enforcing the L1D flushing provides the maximum
537     SMT control and L1D flushing can be tuned by the command line
547     enabled and L1D flushing is not required, but the performance impact is
562  - Flush the L1D cache on every switch from the nested hypervisor to the
566  - Flush the L1D cache on every switch from the nested virtual machine to
567    the nested hypervisor; this is a complex operation, and flushing the L1D
571  - Instruct the nested hypervisor to not perform any L1D cache flush. This
572    is an optimization to avoid double L1D flushing.
586   - L1D conditional flushing on VMENTER when EPT is enabled for