qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony@codemonkey.ws>
To: qemu-devel <qemu-devel@nongnu.org>
Cc: "Kevin Wolf" <kwolf@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Andreas Färber" <afaerber@suse.de>,
	"Stefan Hajnoczi" <stefanha@linux.vnet.ibm.com>
Subject: [Qemu-devel] Semantics of DeviceState::realized and BlockDriverState
Date: Mon, 11 Jun 2012 17:05:03 -0500	[thread overview]
Message-ID: <4FD66B8F.4080203@codemonkey.ws> (raw)

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.

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.

Regard,

Anthony Liguori

             reply	other threads:[~2012-06-11 22:05 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-11 22:05 Anthony Liguori [this message]
2012-06-12  0:29 ` [Qemu-devel] Semantics of DeviceState::realized and BlockDriverState Andreas Färber
2012-06-12  1:26   ` Anthony Liguori
2012-06-12  6:10 ` Paolo Bonzini
2012-06-12  8:07   ` Kevin Wolf
2012-06-12  8:02 ` Kevin Wolf
2012-06-13 12:53 ` Markus Armbruster
2012-06-13 12:55   ` Paolo Bonzini
2012-06-13 13:18   ` Anthony Liguori
2012-06-13 15:44   ` Kevin Wolf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FD66B8F.4080203@codemonkey.ws \
    --to=anthony@codemonkey.ws \
    --cc=afaerber@suse.de \
    --cc=kwolf@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).