Re: [Qemu-devel] Supporting hypervisor specific APIs in libvirt

[Jamie Lokier <jamie@shareable.org>]

Avi Kivity wrote:
> On 03/23/2010 09:31 PM, Anthony Liguori wrote:
> >
> >>
> >>One problem is that this is libvirt version specific.  For example, 
> >>libvirt x doesn't support spice so we control that thorough qmp.  But 
> >>libvirt x+1 does support spice and now it gets confused about all the 
> >>spice messages.
> >
> >That's only a problem if we only support a single QMP session.  This 
> >is exactly why we need to support multiple QMP sessions (and do).
> 
> It's unrelated to the number of sessions.  libvirt expects state that it 
> manages in qemu not to change randomly.  Users know that, so they will 
> only manage non-libvirt state in their private session.  But a new 
> version of libvirt may expand its scope and start managing this area, 
> leading to conflicts.

We have events when state changes, for libvirt to be informed.

But that's prone to race conditions.

A fairly universal solution to that is "pre"-events, where something
that's going to change state emits a pre-event, waits for an ack from
all listeners, then proceeds or not according to the acks, then
finally emits the post-event to say the state is changed.  Between pre
and post events, as far as the listener is concerned, the state is
uncertain and it must query or wait when it needs the value.(*)

In other words, libvirt would register to listen to all the pre-events
for state that it cares about being synchronised with.  When libvirt
expands its scope, it would simply listen to some more.

-- Jamie

(*) Yes, this is like 2-phase transactions, and it's also a bit like
MESI caching.  But it's easier to understand than both :-)