qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 01/17] qidl: add QEMU IDL processor


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 01/17] qidl: add QEMU IDL processor
Date: Wed, 06 Jun 2012 16:27:58 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1

On 06/06/2012 03:45 PM, Avi Kivity wrote:
On 06/06/2012 02:51 AM, Anthony Liguori wrote:
+during device construction and never changes.  This means we can add an
+**_immutable** marker to it:

Even if it does change (suppose we add a monitor command to retarget a
the serial device's chardev), it need not be migrated since it doesn't
describe guest state, only host state.  Maybe we should mark *chr _host
instead of _immutable.

No, this is just another example of C's type system sucking and being
ambiguous.

Consider the following example:

struct PS2Keyboard {
     DeviceState parent;

     PCKBDState _immutable *controller; // link
     ...
};

This is definitely '_immutable' even though *something* has to marshal
that PCKBDState.  That's because this is a reference to an externally
managed object.  As long as references don't change due to guest
initiated actions, they're immutable.

In fact C allows you to express this:

   const T *foo;   // *foo may not change, but foo may
   T * const foo;  // foo may not change, but *foo may

Although every time I see this, I have to stop and think, which activity
I usually try to avoid.  So your example would be written

   PCKBDState * _immutable controller; // link

if we adopt the same system.

I think you meant to add a const in there, but yeah, I know.

 But I wasn't referring to that at all.
Instead, some state is simply not relevant to the guest view, even
though it is state.  We don't have a lot of that since most host state
is behind nice interfaces, but think of a vga device that keeps track of
the host window size and alt-ctrl status.  Those are not guest state and
need not be migrated.

Both the host window size and alt-ctrl status are not device state. They are host backend state and they ought to be stored in a different data structure. This is exactly how we do it (both things are stored in sdl.c or vnc.c).

If we're storing mutable host state in a device structure, that's a bug IMHO. That's sort of the premise of the QIDL annotations at least.

In the case of a CharDriverState, the reference is always immutable.  If
we supported changing char backends dynamically, it would not happen by
changing the reference, but almost certainly by having the ability to
reopen the char driver in place.  IOW, while the referenced object
changes, the reference doesn't change.

In either case, state changes.  The reason we don't send it over is
because it's not guest state, not because we reopen in place or not (and
migration shouldn't depend on how we choose to implement changing
chardev backends -- reopen or delete/new).

Well the goal is here not to support any possible way of separating guest state and host state. The goal is here is to be very opinionated about how we separate guest and host state such that we can take a rigorous approach to migrating guest state.

I think we're actually pretty good today about separating host and guest state. I can't think of an example within devices where we don't cleanly separate things outside of block devices.

Regards,

Anthony Liguori







reply via email to

[Prev in Thread] Current Thread [Next in Thread]