On 2/7/25 15:34, Martin Harvey wrote: > Probably a FAQ. > > I have implemented a prototype: > > * > QEMU event for an in-guest issue (tools installation / crash etc), > via fwcfg / vmcore (similar). (QEMU_PROCESS_EVENT_DBGTOOLS_CHANGED). > * > Qemu Process / QemuMonitor handling for same event. > * > Mapped this through to VIR_DOMAIN_EVENT_ID_DBG_TOOLS, > * > Corresponding changes to top level event handling. > > We would find this *very useful* in cases where vm migration, debugging > and the like require co-operation with guest user-mode. > > Are you folks happy to countenance some simple, but top-level, event > handling changes triggered by guest software, or is this considered a no > no? Should I be burying the details somewhere in EVENT_TUNABLE instead? I don't think this is achievable via EVENT_TUNABLE. I mean, EVENT_TUNABLE is completely detached from QEMU process, it's a libvirt originated event that's fired whenever some knob changes (alright, there are only a few specific cases where this event is emitted, but still). If you need to detect changes made by guest OS in fwcfg then we need QEMU to send an event to libvirt so that it can be relayed to users. Once it's merged in QEMU then libvirt can start supporting it too (we've had bad experience with merging patches in libvirt before they landed in QEMU). But hey, patches can be sent at the same time, it's only merging them that has to be serialized. Michal
