On Tue, Jun 30, 2020 at 02:33:42PM +0200, Paolo Bonzini wrote: > On 30/06/20 12:28, Roman Bolshakov wrote: > > @@ -966,6 +964,20 @@ int hvf_vcpu_exec(CPUState *cpu) > > return ret; > > } > > > > +void hvf_vcpu_kick(CPUState *cpu) > > +{ > > + X86CPU *x86_cpu = X86_CPU(cpu); > > + CPUX86State *env = &x86_cpu->env; > > + hv_return_t err; > > + > > + atomic_set(&env->hvf_deadline, 0); > > + err = hv_vcpu_interrupt(&cpu->hvf_fd, 1); > > + if (err) { > > + fprintf(stderr, "qemu:%s error %#x\n", __func__, err); > > + exit(1); > > + } > > Can a signal interrupt hv_vcpu_run? If so you actually don't need > hv_vcpu_interrupt at all.
Existing signal masking and SIG_IPI didn't work IIRC when I tried to add a primitive version of gdbstub support. > You can also require the preemption time, all > processor that support HVF have it, but never set it by default. The > deadline can be left at 0 all the time; instead, you toggle the bit in > the pin-based controls. In the signal handler you do: > > if (atomic_xchg(&env->hvf_in_guest, false)) { > wvmcs(cpu->hvf_fd, VMCS_PIN_BASED_CTLS, > rvmcs(cpu->hvf_fd, VMCS_PIN_BASED_CTLS) > | VMCS_PIN_BASED_CTLS_VMX_PREEMPT_TIMER); > } > > In the main loop you do: > > atomic_set(&env->hvf_guest_mode, true); > smp_mb(); > hv_vcpu_run(...); > atomic_set(&env->hvf_guest_mode, false); > > and in the preemption timer vmexit handler: > > wvmcs(cpu->hvf_fd, VMCS_PIN_BASED_CTLS, > rvmcs(cpu->hvf_fd, VMCS_PIN_BASED_CTLS) > & ~VMCS_PIN_BASED_CTLS_VMX_PREEMPT_TIMER); > Ok, I'll look into that. Thanks for the advices! -Roman