Re: [PATCH v4 3/4] Introduce the NVMM impl

[Maxime Villard <max@m00nbsd.net>]

Le 11/03/2020 à 22:44, Paolo Bonzini a écrit :
> On 11/03/20 22:21, Maxime Villard wrote:
>>> Yes, you don't know how long that run would take.  I don't know about
>>> NVMM but for KVM it may even never leave if the guest is in HLT state.
>> Ok, I see, thanks.
>>
>> In NVMM the runs are short
> 
> How do you ensure that a guest with interrupts off exits promptly?

In NVMM there are several conditions unrelated to the guest state which
cause returns to userland. These are reschedulings, signals and softints.
They happen "regularly". As the man page states: "this gives a chance
for emulator software to halt the VM in its tracks".

There was a specific reason this design was chosen, but it's true that a
nvmm_vcpu_kick() is more precise and warranted here.

>> , the syscalls are fast, and pending signals
>> cause returns to userland. Therefore, in practice, it's not a big problem,
>> because (1) the window is small and (2) if we have a miss it's not going
>> to take long to come back to Qemu.
>>
>> I see a quick kernel change I can make to reduce 95% of the window
>> already in the current state. The remaining 5% will need a new
>> nvmm_vcpu_kick() function.
> 
> You can also do what KVM did until a few years ago: swap the signal mask
> atomically when you enter the hypervisor (e.g. unmasking SIGUSR1---this
> has to be done in the kernel) and when you leave it.  Then in QEMU you
> keep SIGUSR1 masked and "eat" it with sigwaitinfo.
> 
>> For now this issue is unimportant and no Qemu change is required.
> 
> If you say so.

At first I thought the race was an actual locking problem. In fact it's
just a delay which on NVMM happens to be small, so yeah, not a very
important issue, it will be addressed in a future patch set soon.

Thanks,
Maxime