qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Re: [PATCH 0/8] kvm: Fixes, cleanups and live migratio


From: Gleb Natapov
Subject: Re: [Qemu-devel] Re: [PATCH 0/8] kvm: Fixes, cleanups and live migration
Date: Sat, 2 May 2009 20:23:08 +0300

On Sat, May 02, 2009 at 08:50:08AM -0500, Anthony Liguori wrote:
> Gleb Natapov wrote:
>> On Fri, May 01, 2009 at 05:40:00PM -0500, Anthony Liguori wrote:
>>   
>>> Jan Kiszka wrote:
>>>     
>>>> Besides refreshed versions of my already posted fixes and cleanups for
>>>> KVM, this series comes with patches to enable live migration in KVM
>>>> mode. If there is still some migration bit missing compared to qemu-kvm,
>>>> please let me know.
>>>>         
>>> In qemu-kvm, we also save:
>>>
>>> MSR_IA32_TSC
>>> mp_state
>>> interrupt_bitmap
>>>
>>> In QEMU, we probably should just emulate MSR_IA32_TSC and then we can 
>>>  reuse that for save/restore.
>>>
>>> interrupt_bitmap is a bit more tricky.  It only ever can have one bit 
>>>  set AFAICT but I don't see anything that we're currently saving that 
>>>  maps to it which leads me to wonder why KVM needs it and QEMU 
>>> doesn't.
>>>
>>>     
>> KVM stores pending interrupt there (interrupt that is not in irq chip
>> already but not yet injected to vcpu). I have patch (not yet submitted)
>> that removes the use of interrupt_bitmap from kernel. It recreated only
>> for migration bits. My plan is to change migration bits too, but it is
>> trickier if we want to keep backwards compatibility. No need to
>> introduce interrupt_bitmap in qemu upstream IMO. We need to migrate
>> pending interrupt though. The info that should be migrated it interrupt
>> vector, interrupt type (soft/hw) and instruction length (needed for
>> injection of soft interrupts on VMX).
>>   
>
> I think the right thing to do with this is introduce a kvm-cpu savevm  
> that stores this information since it isn't relevant to TCG.  I think  
> it's arguable whether you want instruction length there (can you get it  
> reliably on SVM?).
>
We can't get it on SVM without instruction decoding, but it is not required
on SVM. It is absolutely essential for soft interrupt/exception injection
on VMX and has to be a part of migratable state.

> If we did that, v1 could be interrupt_bitmap and then v2 can be this new  
> data layout.
>
> Regards,
>
> Anthony Liguori
>
>> --
>>                      Gleb.
>>
>>
>>   

--
                        Gleb.




reply via email to

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