From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=55600 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Q4G8O-0006WM-9M
	for qemu-devel@nongnu.org; Mon, 28 Mar 2011 13:21:45 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <blauwirbel@gmail.com>) id 1Q4G8M-0003If-8x
	for qemu-devel@nongnu.org; Mon, 28 Mar 2011 13:21:43 -0400
Received: from mail-vx0-f173.google.com ([209.85.220.173]:37020)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <blauwirbel@gmail.com>) id 1Q4G8M-0003IO-5W
	for qemu-devel@nongnu.org; Mon, 28 Mar 2011 13:21:42 -0400
Received: by vxb41 with SMTP id 41so2822768vxb.4
	for <qemu-devel@nongnu.org>; Mon, 28 Mar 2011 10:21:40 -0700 (PDT)
MIME-Version: 1.0
In-Reply-To: <4D9037EE.8000808@redhat.com>
References: <AANLkTikkPbsov3it21-j=Fs12jz21-b0C=iG09WMwx7V@mail.gmail.com>
	<4D9037EE.8000808@redhat.com>
From: Blue Swirl <blauwirbel@gmail.com>
Date: Mon, 28 Mar 2011 20:21:19 +0300
Message-ID: <AANLkTim48ir6-PYdLCGBA68mS9_3M+Vi4Syv60EhqSU=@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Subject: [Qemu-devel] Re: [PATCH 3/4] Introduce machine state
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: qemu-devel <qemu-devel@nongnu.org>

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].