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: Blue Swirl
Subject: Re: [Qemu-devel] [PATCH 28/35] kvm: x86: Introduce kvmclock device to save/restore its state
Date: Fri, 21 Jan 2011 18:49:16 +0000

On Fri, Jan 21, 2011 at 6:17 PM, Jan Kiszka <address@hidden> wrote:
> On 2011-01-21 19:04, Blue Swirl wrote:
>> On Fri, Jan 21, 2011 at 5:21 PM, Jan Kiszka <address@hidden> wrote:
>>> 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.
>>
>> Excellent plan.
>>
>>> Obvious classes are
>>>  - static host capabilities and means for the KVM core to query them
>>
>> OK. There could be other host capabilities here in the future too,
>> like Xen. I don't think there are any Xen capabilities ATM though but
>> IIRC some recently sent patches had something like those.
>>
>>>  - per-VM fields
>>
>> What is per-VM which is not machine or CPU architecture specific?
>
> I think it would suffice for a first step to consider all per-VM fields
> as independent of CPU architecture or machine type.

I'm afraid that would not be progress.

>>>  - fields related to memory management
>>
>> OK.
>>
>> I'd add fourth possible class:
>>  - device, CPU and machine configuration, like nographic,
>> win2k_install_hack, no_hpet, smp_cpus etc. Maybe also
>> irqchip_in_kernel could fit here, though it obviously depends on a
>> host capability too.
>
> I would count everything that cannot be assigned to a concrete device
> upfront to the dynamic state of a machine, thus class 2. The point is,
> (potentially) every device of that machine requires access to it, just
> like (indirectly, via the KVM core services) to some KVM VM state bits.

The machine class should not be a catch-all, it would be like
QEMUState or KVMState then. Perhaps each field or variable should be
listed and given more thought.



reply via email to

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