Re: [PATCH] KVM: nVMX: initialize PML fields in vmcs02

[Paolo Bonzini <pbonzini@redhat.com>]

On 04/04/2017 15:25, David Hildenbrand wrote:
> On 04.04.2017 15:09, David Hildenbrand wrote:
>>
>>>>> +     if (enable_pml) {
>>>>> +             /*
>>>>> +              * Conceptually we want to copy the PML address and index from
>>>>> +              * vmcs01 here, and then back to vmcs01 on nested vmexit. But,
>>>>> +              * since we always flush the log on each vmexit, this happens
>>>>
>>>> we == KVM running in g2?
>>>>
>>>> If so, other hypervisors might handle this differently.
>>>
>>> No, we as KVM in L0. Hypervisors running in L1 do not see PML at all,
>>> this is L0-only code.
>>
>> Okay, was just confused why we enable PML for our nested guest (L2)
>> although not supported/enabled for guest hypervisors (L1). I would have
>> guessed that it is to be kept disabled completely for nested guests
>> (!SECONDARY_EXEC_ENABLE_PML).
>>
>> But I assume that this a mysterious detail of the MMU code I still have
>> to look into in detail.
>>
> 
> So for secondary exec controls we:
> 
> 1. enable almost any exec control enabled also for our L1 (except 4 of
> them)
> -> slightly scary, but I hope somebody thought well of this
> 2. blindly copy over whatever L2 gave us

You mean L1 here.  I am also not sure if you mean:

- blindly copy to vmcs02 whatever L1 gave us

- or, fill vmcs02 with vmcs01 contents, blindly ignoring whatever L1 gave us

but I can explain both.

1) As Ladi said, most VMCS fields are checked already earlier

2) Some features are not available to the L1 hypervisor, or they are
emulated by KVM.  When this happens, the relevant fields aren't copied
from vmcs12 to vmcs02.  An example of emulated feature is the preemption
timer; an example of unavailable feature is PML.

In fact, when we implement nested PML it will not use hardware PML;
rather it will be implemented by the KVM MMU.  Therefore it will still
be okay to overwrite these two fields and to process PML vmexits in L0.
Whenever the MMU will set a dirty bit, it will also write to the dirty
page log and possibly trigger an L1 PML vmexit.  But PML vmexits for L0
and L1 will be completely different---L0's comes from the processor
while L1's are injected by the parent hypervisor.

> Especially if I am not wrong:
> 
> PML available on HW but disabled by setting "enable_pml = 0".
> L1 blindly enabling PML for L2.
>
> We now run our vmcs02 with SECONDARY_EXEC_ENABLE_PML without pml regions
> being set up.
> 
> Am I missing a whitelist somewhere? I hope so. Such things should always
> have whitelists.

Does the above explain it?

Paolo