On 4/25/19 1:31 PM, Daniel Henrique Barboza wrote:
Thanks for the explanation and fixing before pushing. I was under the
impression
that the now extinct line:
"if (qemuDomainObjBeginAgentJob(driver, vm, QEMU_AGENT_JOB_MODIFY) < 0)"
Was enough to hold the lock context for all the VM resources, not only
the QEMU
agent. Mostly because I saw the usage of:
if (qemuDomainObjBeginJob(driver, vm, QEMU_JOB_MODIFY) < 0)
Right below, in qemuDomainPMWakeup(), that access the monitor in the same
function.
But now that I'm putting it all together I noticed that the functions
are all different .... so qemuDomainObjBeginJob() locks the monitor,
qemuDomainObjBeginAgentJob() locks the agent, and
qemuDomainObjBeginJobWithAgent() can lock both, depending if
job isn't QEMU_JOB_NONE. Is this somewhat close to the actual usage?
Exactly. Previously we had only one job condition where all threads had
to serialize. I mean one condition per VM. So even if you had two APIs:
one wanted to talk on monitor and the other wanted to talk to the guest
agent they would serialize. This is obviously suboptimal. So I've split
the condition into two. The downside is that we have to be more careful
which job we must take (and there's no job promotion as in 'I already
have say monitor job and now I realized I need an agent job too').
Michal
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
