qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 28/35] kvm: x86: Introduce kvmclock device to sa


From: Jan Kiszka
Subject: Re: [Qemu-devel] [PATCH 28/35] kvm: x86: Introduce kvmclock device to save/restore its state
Date: Fri, 21 Jan 2011 18:21:56 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

On 2011-01-21 17:37, Blue Swirl wrote:
> On Fri, Jan 21, 2011 at 8:46 AM, Gerd Hoffmann <address@hidden> wrote:
>>  Hi,
>>
>>> By the way, we don't have a QEMUState but instead use globals.
>>
>> /me wants to underline this.
>>
>> IMO it is absolutely pointless to worry about ways to pass around kvm_state.
>>  There never ever will be a serious need for that.
>>
>> We can stick with the current model of keeping global state in global
>> variables.  And just do the same with kvm_state.
>>
>> Or we can move to have all state in a QEMUState struct which we'll pass
>> around basically everywhere.  Then we can simply embed or reference
>> kvm_state there.
>>
>> I'd tend to stick with the global variables as I don't see the point in
>> having a QEMUstate.  I doubt we'll ever see two virtual machines driven by a
>> single qemu process.  YMMV.
> 
> Global variables are signs of a poor design.

s/are/can be/.

> QEMUState would not help
> that, instead more specific structures should be designed, much like
> what I've proposed for KVMState. Some of these new structures should
> be even passed around when it makes sense.
> 
> But I'd not start kvm_state redesign around global variables or QEMUState.

We do not need to move individual fields yet, but we need to define
classes of fields and strategies how to deal with them long-term. Then
we can move forward, and that already in the right direction.

Obvious classes are
 - static host capabilities and means for the KVM core to query them
 - per-VM fields
 - fields related to memory management

And we now need at least a plan for the second class to proceed with the
actual job.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux



reply via email to

[Prev in Thread] Current Thread [Next in Thread]