>
> This is what I'd like. The kernel apic state doesn't have to
> be exactly
> equal to APICState; we just have to write functions to convert into
> APICState and back. That ensures the protocol doesn't change.
>
> (in this way we can even switch kernel apic on and off at runtime
> (not that w
Dong, Eddie wrote:
>>> "copy" means we define some device "state" both in kernel & user.
>>> I.e. kernel use user level state definition.
>>>
>>>
>> Sorry, I don't understand.
>>
>> Here's apic_save(), for example:
>>
>> static void apic_save(QEMUFile *f, void *opaque)
>> {
>>APICState
>>
>> "copy" means we define some device "state" both in kernel & user.
>> I.e. kernel use user level state definition.
>>
>
> Sorry, I don't understand.
>
> Here's apic_save(), for example:
>
> static void apic_save(QEMUFile *f, void *opaque)
> {
>APICState *s = opaque;
>int i;
>
>
Dong, Eddie wrote:
> Avi Kivity wrote:
>
>> Dong, Eddie wrote:
>>
>>> When thinking about live migration support for in kernel irqchip, one
>>> question comes out which need to be solved first:
>>> Do we need to support live migration among user level irqchip and
>>> kernel level?
>>>
Avi Kivity wrote:
> Dong, Eddie wrote:
>> When thinking about live migration support for in kernel irqchip, one
>> question comes out which need to be solved first:
>> Do we need to support live migration among user level irqchip and
>> kernel level?
>
> Yes.
>
>> If the answer is yes, kernel lev
Dong, Eddie wrote:
> When thinking about live migration support for in kernel irqchip, one
> question comes out which need to be solved first:
> Do we need to support live migration among user level irqchip and kernel
> level?
Yes.
> If the answer is yes, kernel level irqchip must keep same stat
When thinking about live migration support for in kernel irqchip, one
question comes out which need to be solved first:
Do we need to support live migration among user level irqchip and kernel
level? If the answer is yes, kernel level irqchip must keep same state
with user level, i.e. if Qemu chang
