On 30/06/20 17:50, Roman Bolshakov wrote: > 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 try pthread_kill followed by hv_vcpu_interrupt if it doesn't. The signal would be delivered after return to userspace. Paolo >> 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 >