[MODERATED] Re: [PATCH v2 4/4] L1TF KVM ARCH_CAPABILITIES #4

[Paolo Bonzini <pbonzini@redhat.com>]

On 30/07/2018 23:36, speck for Thomas Gleixner wrote:
> On Wed, 25 Jul 2018, speck for Paolo Bonzini wrote:
>>  
>> +3.4. Nested virtual machines
>> +""""""""""""""""""""""""""""
>> +
>> +When nested virtualization is in use, three operating systems are involved:
>> +the bare metal hypervisor, the nested hypervisor, and the nested virtual
>> +machine.  VMENTER operations from the nested hypervisor into the nested
>> +guest will always be processed by the bare metal hypervisor.  Therefore:
>> +
>> +When running as a bare metal hypervisor, instead, KVM will:
>> +
>> + - flush the L1D cache on every switch from nested hypervisor to
>> +   nested virtual machine, so that the nested hypervisor's secrets
>> +   are not exposed to the nested virtual machine;
>> +
>> + - flush the L1D cache on every switch from nested virtual machine to
>> +   nested hypervisor; this is a complex operation, and flushing the L1D
>> +   cache avoids that the bare metal hypervisor's secrets be exposed
>> +   to the nested virtual machine;
>> +
>> + - instruct the nested hypervisor to not perform any L1D cache flush.
> 
> I still think that we need some explanation about SMT in guests, i.e. that
> the SMT information in guests is inaccurate and does not tell anything
> about the host side SMT control state. But that's independent of this
> nested optimization as it applies to all guest levels.
> 
>> +u64 kvm_get_arch_capabilities(void)
>> +{
>> +	u64 data;
>> +
>> +	rdmsrl_safe(MSR_IA32_ARCH_CAPABILITIES, &data);
>> +	if (l1tf_vmx_mitigation != VMENTER_L1D_FLUSH_NEVER)
>> +		data |= ARCH_CAP_SKIP_VMENTRY_L1DFLUSH;
> 
> That really wants a comment explaining the magic here.

Something like:

	/*
	 * If we're doing cache flushes (either "always" or "cond")
	 * we will do one whenever the guest does a vmlaunch/vmresume.
	 * If an outer hypervisor is doing the cache flush for us
	 * (VMENTER_L1D_FLUSH_NESTED_VM), we can safely pass that
	 * capability to the guest too, and if EPT is disabled we're not
	 * vulnerable.  Overall, only VMENTER_L1D_FLUSH_NEVER will
	 * require a nested hypervisor to do a flush of its own.
	 */

?

> 
> Thanks,
> 
> 	tglx
>