On Tue, Apr 4, 2017 at 3:25 PM, David Hildenbrand <david@xxxxxxxxxx> 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
> -> very scary
>
> 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.
I believe that this is covered in check_vmentry_prereqs:
!vmx_control_verify(vmcs12->secondary_vm_exec_control,
vmx->nested.nested_vmx_secondary_ctls_low,
vmx->nested.nested_vmx_secondary_ctls_high) ||
where vmx->nested.nested_vmx_secondary_ctls_* represent the whitelist.
> --
>
> Thanks,
>
> David
