[MODERATED] Re: [PATCH 1/2] L1TF KVM 1

[Andrew Cooper <andrew.cooper3@citrix.com>]

[-- Attachment #1: Type: text/plain, Size: 1698 bytes --]

On 29/05/2018 23:49, speck for Thomas Gleixner wrote:
> On Tue, 29 May 2018, speck for Paolo Bonzini wrote:
>> +static void *__read_mostly empty_zero_pages;
>> +
>> +void kvm_l1d_flush(void)
>> +{
>> +	asm volatile(
>> +		"movq %0, %%rax\n\t"
>> +		"leaq 65536(%0), %%rdx\n\t"
> Why 64K?
>
>> +		"11: \n\t"
>> +		"movzbl (%%rax), %%ecx\n\t"
>> +		"addq $4096, %%rax\n\t"
>> +		"cmpq %%rax, %%rdx\n\t"
>> +		"jne 11b\n\t"
>> +		"xorl %%eax, %%eax\n\t"
>> +		"cpuid\n\t"
> What's the cpuid invocation for?
>
>> +		"xorl %%eax, %%eax\n\t"
>> +		"12:\n\t"
>> +		"movzwl %%ax, %%edx\n\t"
>> +		"addl $64, %%eax\n\t"
>> +		"movzbl (%%rdx, %0), %%ecx\n\t"
>> +		"cmpl $65536, %%eax\n\t"
> And this whole magic should be documented.
>
>> +		"jne 12b\n\t"
>> +		"lfence\n\t"
>> +		:
>> +		: "r" (empty_zero_pages)
>> +		: "rax", "rbx", "rcx", "rdx");
> How is that supposed to compile on 32bit?
>
>> +}
> Aside of that do we really need that manual flush thingy? Is that ucode
> update going to take forever?

I already provided feedback on this software loop, but have had radio
silence as a result.  The CPUID is serialisation (best as I can guess)
to terminate any WC buffer which got hit, but this is going to truly
suck inside a VM.  If it is for full serialisation properties, the least
overhead option would be a write to %cr2, which is serialising on all
affected parts.

Other bits I don't understand are the 64k limit in the first place, why
it gets walked over in 4k strides to begin with (I'm not aware of any
prefetching which would benefit that...) and why a particularly
obfuscated piece of magic is used for the 64byte strides.

~Andrew