On Mon, May 25, 2020 at 10:02:27AM +0200, Martin Pieuchot wrote: > On 24/05/20(Sun) 07:56, Dave Voutila wrote: > > On Sat, May 23, 2020 at 9:38 PM Dave Voutila <d...@sisu.io> wrote: > > > > > > Hello tech@, > > > > > > Attached is a diff that patches vmd(8) to utilize libevent 2.1 (from > > > ports) in an attempt to test the hypothesis that thread safety will > > > help stabilize Linux guest support. There's some longer detail below > > > about this hypothesis, but let me cut to the chase: > > > > I failed to pose the hypothesis more concretely. > > > > If I understand vmd(8) correctly, the process created by the 'vmm' > > process (after privsep) forks to create a 'vm' process representing > > the guest. After this fork, there's a call to vmm.c::vmm_pipe(), which > > adds an event to the event_base to deal with imsg's. Once in > > vm.c::run_vm(), a pthread is created (the 'event_thread') that > > initiates the event pump/loop. My speculation is this design is > > leading to spurious issues with the libevent state in the event_base. > >[...] > > > > > > - Rework the vm.c event handling to not be multi-threaded? > > I'd say that or fix base's libevent. Both imply understanding precisely > what the race/corruption is. > > Do all the threads need to modify libevent's states? What for?
The problem is that the vm exit is handled by a different thread then the event loop. So some event_add/evtimer_add calls are done from a different thread then the main event loop (mainly interrupt processing). One approach to fix this is to ensure that the event functions are exclusivly used in the main event thread but as usual it is easy to introduce bugs again. I don't think there is a way to fix/change our libevent code without major drawbacks for all other libevent users. -- :wq Claudio
