On Thu, Jun 25, 2020 at 03:30:38PM +0200, Paolo Bonzini wrote: > On 25/06/20 14:36, Roman Bolshakov wrote: > > > > Yes, there's such a place. post-init and post-reset invoke > > hvf_put_registers() and the latter one calls hvf_put_segments(). > > hvf_put_segments() sets CR4 and CR0 via macvm_set_cr0/macvm_set_cr4 > > using the CR0/CR4 from env. So, the reset is relying on generic QEMU > > CPUX86State now. LMA in EFER is reset there as well. > > Ok, do you want to send a follow-up or a v2 of this? >
I'm still trying to understand what I should do :) > > 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. > macvm_set_cr0() sets/clears LMA in entry controls only in case of transitions into/out of long mode in enter_long_mode() in exit_long_mode(), respectively. But macvm_set_cr0() doesn't load EFER.LMA from CPUX86State into VMCS entry controls during reset and that's where hvf_put_registers() might not behave properly. As far as I understand you propose to drop explicit LMA reset in post-reset and rather impove synchronization between efer and entry controls in macvm_set_cr0(), right? In that case I don't see a regression in the series, and if possible I'd prefer a follow up patch for the issue. > PDPTEs are not a problem, because they are not used after reset (only if > CR4.PAE=CR4.PG=1 and EFER.LME=0). > Ok, good, then we're leaving PDPTE initialization as is in post-reset. Thanks, Roman
