From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Hildenbrand Subject: Re: [PATCH] KVM: nVMX: initialize PML fields in vmcs02 Date: Tue, 4 Apr 2017 16:22:09 +0200 Message-ID: <56e1c61e-5bb8-8363-ce01-7e56d1455fdc@redhat.com> References: <20170404121853.28057-1-lprosek@redhat.com> <903edb56-6e81-b528-cc20-a710e91aba3b@redhat.com> <01e8ab04-4e16-ac99-bb1d-994bbd937787@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: KVM list , kai.huang@linux.intel.com, Wanpeng Li To: Paolo Bonzini , Ladi Prosek Return-path: Received: from mx1.redhat.com ([209.132.183.28]:53982 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752459AbdDDOWM (ORCPT ); Tue, 4 Apr 2017 10:22:12 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: >> >> 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