[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 6/8] i386: hvf: Drop hvf_reset_vcpu()
From: |
Roman Bolshakov |
Subject: |
Re: [PATCH 6/8] i386: hvf: Drop hvf_reset_vcpu() |
Date: |
Thu, 25 Jun 2020 15:36:37 +0300 |
On Thu, Jun 25, 2020 at 12:31:49PM +0200, Paolo Bonzini wrote:
> On 25/06/20 00:58, Roman Bolshakov wrote:
> > + uint64_t pdpte[4] = {0, 0, 0, 0};
> > + int i;
> > +
> > + /* Reset IA-32e mode guest (LMA) */
> > + wvmcs(cpu->hvf_fd, VMCS_ENTRY_CTLS, 0);
> > +
>
> Where is the place (if any...) that calls macvm_set_cr0 and
> macvm_set_cr4 from cpu_synchronize_*? If you have such a place it
> should take care of resetting LMA as well. Assuming that no entry
> controls are ever set is quite fragile.
>
Hi Paolo,
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.
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.
Is there an outstanding issue I'm missing?
Regards,
Roman
- [PATCH 0/8] Improve synchronization between QEMU and HVF, Roman Bolshakov, 2020/06/24
- [PATCH 1/8] i386: hvf: Set env->eip in macvm_set_rip(), Roman Bolshakov, 2020/06/24
- [PATCH 3/8] i386: hvf: Add hvf_cpu_synchronize_pre_loadvm(), Roman Bolshakov, 2020/06/24
- [PATCH 2/8] i386: hvf: Move synchronize functions to sysemu, Roman Bolshakov, 2020/06/24
- [PATCH 7/8] i386: hvf: Clean up synchronize functions, Roman Bolshakov, 2020/06/24
- [PATCH 6/8] i386: hvf: Drop hvf_reset_vcpu(), Roman Bolshakov, 2020/06/24
[PATCH 5/8] i386: hvf: Don't duplicate register reset, Roman Bolshakov, 2020/06/24
[PATCH 4/8] i386: hvf: Implement CPU kick, Roman Bolshakov, 2020/06/24