On Thu, Jun 25, 2020 at 03:30:38PM +0200, Paolo Bonzini wrote: > On 25/06/20 14:36, Roman Bolshakov wrote: > > I don't know any alternative for PDPTE and VMCS Entry Controls in > > CPUX86State, that's why I left explicit reset of the VMCS fields in > > post-reset. > > VMCS entry controls should be handled by macvm_set_cr0 as well, because > QEMU does not use any except for the LMA bit. They are initialized zero > > wvmcs(cpu->hvf_fd, VMCS_ENTRY_CTLS, > cap2ctrl(hvf_state->hvf_caps->vmx_cap_entry, 0)); > > but in practice the last argument ends up being zero all the time. > > PDPTEs are not a problem, because they are not used after reset (only if > CR4.PAE=CR4.PG=1 and EFER.LME=0). >
Paolo, I'm not sure if I properly understand it yet but I don't see any specific requirements on PDPTE's reset. SDM says that it should be valid only if PAE is used as documented in 26.3.1.6 Checks on Guest Page-Directory-Pointer-Table Entries: "A VM entry to a guest that does not use PAE paging does not check the validity of any PDPTEs. A VM entry that checks the validity of the PDPTEs uses the same checks that are used when CR3 is loaded with MOV to CR3 when PAE paging is in use. If MOV to CR3 would cause a general-protection exception due to the PDPTEs that would be loaded (e.g., because a reserved bit is set), the VM entry fails." That means we can drop PDPTE initialization in hv_vcpu_reset() as well. Perhaps, I can try that and check if Windows XP with PAE support works well alright across resets. macvm_set_cr0() takes care of setting PDPTEs upon the entry into PAE mode. Regards, Roman
