Questions about using qemuProcess API within a libvirt test

Michal Privoznik mprivozn at redhat.com
Wed Feb 12 07:48:38 UTC 2020


On 2/10/20 10:01 PM, Collin Walling wrote:
> Hello,
> 

Apart from what Laine said, this looks like your test binary is missing 
event loop. The way sending QMP commands work is that you have one 
thread, that wants to send a QMP command. It will construct the command, 
format JSON string out of it and notifies the other thread (where the 
event loop is running) and goes to sleep. The other thread waits until 
QMP socket becomes writable (poll()) and then writes the JSON string 
into it. Then it waits until the socket becomes readable and when it 
does so, it reads incoming data (which is a reply to the command). Once 
the full reply was received it will wake up the original thread [1].

Adding an event loop to your program should be easy. Just see what 
tests/qemucapsprobe.c is doing. Important bits are eventLoop() function 
and virEventRegisterDefaultImpl() and virThreadCreate() calls.

However, as Laine says, we don't want our test suite to spawn any qemu 
process. Not only it would create a non-reproducible environment for the 
tests (developers might run different version of qemu), it might also 
not work at all - when building libvirt we don't require qemu to be 
installed (as we don't link with it, there is no library to link with 
anyways). But we want our test suite to run successfully.

When we want to test something that talks on QMP monitor (e.g. 
qemumonitorjsontest), we create two threads and provide an alternative 
implementation for the event loop - instead of actually touching any 
real QMP monitor socket, it discards all writes, and provides well 
defined replies (crafted before). Look into the source file and you will 
understand.

Michal

1: In fact, the event loop always poll()-s for socket to be readable, 
because QEMU can send us an event asynchronously, but let's not 
complicate things right now.




More information about the libvir-list mailing list