>> >> 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: I keep messing up L0/L1/... as the terminology I am used from s390x was different.. (L0 == LPAR). But you had the right intention. > > - 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. It was actually a mixture of both :) > > 1) As Ladi said, most VMCS fields are checked already earlier It took longer to understand how these checks work than it should. But this was what I was looking for. nested_vmx_secondary_ctls_high == whitelist as Ladi pointed out (bits that may be set). And PML should never be set. > > 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? Yes, perfectly well, thanks a lot! > > Paolo > -- Thanks, David
