qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Blue Swirl <blauwirbel@gmail.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: qemu-devel <qemu-devel@nongnu.org>
Subject: [Qemu-devel] Re: [PATCH 3/4] Introduce machine state
Date: Mon, 28 Mar 2011 20:21:19 +0300	[thread overview]
Message-ID: <AANLkTim48ir6-PYdLCGBA68mS9_3M+Vi4Syv60EhqSU=@mail.gmail.com> (raw)
In-Reply-To: <4D9037EE.8000808@redhat.com>

On Mon, Mar 28, 2011 at 10:25 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
> On 03/26/2011 11:28 PM, Blue Swirl wrote:
>>
>> Move generic machine state to machine-state.h, adjust
>> users.
>
> What's the distinction between vm state and machine state?

Machine state or configuration is visible to guest, for example number
of CPUs. Machine level actions are also guest visible, for example
hotplugging.

VM state should be invisible (except for PV devices).

> Perhaps your vm state is more appropriately called "emulator state" (i.e.
> sits between host and vm), and machine state is actually "vm state"?

I agree that the names are not so great. But 'emulator' is a bit
generic. About 'machine', I was thinking about -M switch to specify
the emulated machine type.

> BTW, uuid should be in machine state rather than (your definition of) vm
> state.

Right.

About patch sequencing, it should be possible to avoid most of the
changes until the last patch set, by adding for example
#include "vm-state.h"
to sysemu.h when vm-state.h is introduced. The last patch, which
removes sysemu.h, would adjust all sysemu.h users at once.

If the general view is that this patch set goes to the right
direction, the next step after machine/vm state would be to introduce
generic VCPU state, probably based on cpus.[ch].

  reply	other threads:[~2011-03-28 17:21 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-26 22:28 [Qemu-devel] [PATCH 3/4] Introduce machine state Blue Swirl
2011-03-28  7:25 ` [Qemu-devel] " Paolo Bonzini
2011-03-28 17:21   ` Blue Swirl [this message]
2011-03-29  8:14     ` Paolo Bonzini
2011-03-29 17:50       ` Blue Swirl

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='AANLkTim48ir6-PYdLCGBA68mS9_3M+Vi4Syv60EhqSU=@mail.gmail.com' \
    --to=blauwirbel@gmail.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /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).