[Qemu-devel] Re: [PATCH 3/4] Introduce machine state
On 03/28/2011 07:21 PM, Blue Swirl wrote: What's the distinction between vm state and machine state? VM state should be invisible (except for PV devices). Got it. That's why I called it emulator state (a bit generic, but more precise than vm state: vm_clock for example is guest-visible). About 'machine', I was thinking about -M switch to specify the emulated machine type. Yes, makes sense. I actually like the name machine state, as long as you rename what you called virtual machine state. Paolo
[Qemu-devel] Re: [PATCH 3/4] Introduce machine state
On Tue, Mar 29, 2011 at 11:14 AM, Paolo Bonzini pbonz...@redhat.com wrote: On 03/28/2011 07:21 PM, Blue Swirl wrote: What's the distinction between vm state and machine state? VM state should be invisible (except for PV devices). Got it. That's why I called it emulator state (a bit generic, but more precise than vm state: vm_clock for example is guest-visible). About 'machine', I was thinking about -M switch to specify the emulated machine type. Yes, makes sense. I actually like the name machine state, as long as you rename what you called virtual machine state. OK, I'll change 'vm' to 'emulator'. Thanks for the review.
[Qemu-devel] Re: [PATCH 3/4] Introduce machine state
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? Perhaps your vm state is more appropriately called emulator state (i.e. sits between host and vm), and machine state is actually vm state? BTW, uuid should be in machine state rather than (your definition of) vm state. Paolo
[Qemu-devel] Re: [PATCH 3/4] Introduce machine state
On Mon, Mar 28, 2011 at 10:25 AM, Paolo Bonzini pbonz...@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].
