Re: [Qemu-devel] Semantics of DeviceState::realized and BlockDriverState

[Markus Armbruster]

Anthony Liguori <address@hidden> writes:

> Hi,
>
> I wanted to start a central thread as this discussion is spread in two
> places right now.
>
> I think I'm becoming convinced that realized belongs in DeviceState
> and that BlockDriverState does not have a realized equivalent.
>
> To me, realized represents Vcc.  When realized=true, the guest has
> power and is active.  When realized=false, the guest has lost power.
> The realize() event is the rising edge of Vcc, unrealized() is the
> falling edge.
>
> realize() should be used to take any actions that require all
> parameters to be set that need to happen before the guest has power.
> This later clause is extremely important.  unrealize() should be used
> to unset anything setup in realize().
>
> The destructor being invoked does not imply that unrealize() has happened.
>
> I think BlockDriverState wants two separate signals: an opened signal
> and an attached signal.
>
> With BDS, there are a few phases:
>
> opened = false
> attached = false
>
> All properties can be set here and no side effects occur.
>
> It is not valid to do a read/write request to a BDS in this state.
>
> opened = true
> attached = false
>
> Properties that affect file opening (flags and filename) cannot be
> changed after this point.  Depending on the contents of the file, a
> backing_file property may be created after opened = true.  The
> backing_file that gets created does *not* automatically have opened =
> true.  A user explicitly needs to set that.
>
> This behavior is necessary to allow overriding backing files.

Could you explain why we need to override backing files between open and
attach?

Can you give another example of something we need to be able to do
between open and attach?

> It is not valid to do a read/write request to a BDS in this state.
>
> opened = true
> attached = true
>
> This means that the device is in-use by something in QEMU.  Requests
> may be in flight as read/write requests are now allowed to be issued.
>
> Most properties cannot be changed in this state (presumably).
>
> opened = false
> attached = true
>
> Invalid state.
>
> So there are three valid states and none of them map directly to the
> concept of realized for devices.
>
> I think this argues pretty clearly for realize() to not live in Object
> and instead to allow base classes to implement whatever properties
> make sense to them.

I'm not yet convinced.

QOM design started with two states: unrealized and realized.

For block backends, you suggest we need to split the unrealized state.
I'm not sure that's actually necessary.  But even if it is, the result
still satisfies the unrealized/realized contract:

1. While unrealized, all you can do is set properties.  Setting a
   property may fail.

2. While realized, the object "can do stuff", but its properties are
   typically immutable.

Yes, that's a pretty vague contract.  But TYPE_OBJECT is a pretty
abstract thing, so some vagueness may be unavoidable.  If you can come
up with a tighter one, excellent.

Note that a BDS satisfies 1. whether it's opened or not.