Re: [Qemu-devel] Re: [PATCH 26/35] kvm: Eliminate KVMState arguments

[Alexander Graf]

On 11.01.2011, at 16:12, Anthony Liguori wrote:

> On 01/11/2011 08:56 AM, Avi Kivity wrote:
>> On 01/11/2011 04:36 PM, Anthony Liguori wrote:
>>>> They need to use the same device id then.  And if they share code, that 
>>>> indicates that they need to be the same device even more.
>>> 
>>> 
>>> No, it really doesn't :-)  Cirrus VGA and std VGA share a lot of code.  But 
>>> that doesn't mean that we treat them as one device.
>> 
>> Cirrus and VGA really are separate devices.  They share code because on 
>> evolved from the other, and is backwards compatible with the other.  i8254 
>> and i8254-kvm did not evolve from each other,
> 
> Actually, they did, but that's besides the point.
> 
>> both are implementations of the i8254 spec, and both are 100% compatible 
>> with each other (modulu bugs).
>> 
>>> 
>>> And BTW, there are guest visible differences between the KVM IOAPIC/PIC/PIT 
>>> than the QEMU versions.  The only reason PIT live migration works today is 
>>> because usually delivers all interrupts quickly.  But it actually does 
>>> maintain state in the work queue that isn't saved.  If PIT tried to 
>>> implement gradual catchup, there would be no way not to expose that state 
>>> to userspace.
>> 
>> Why not?  Whatever state the kernel keeps, we expose to userspace and allow 
>> sending it over the wire.
> 
> What exactly is the scenario you're concerned about?
> 
> Migration between userspace HPET and in-kernel HPET?
> 
> One thing I've been considering is essentially migration filters.  It would 
> be a set of rules that essentially were "hpet-kvm.* = hpet.*" which would 
> allow migration from hpet to hpet-kvm given a translation of state.  I think 
> this sort of higher level ruleset would make it easier to support migration 
> between versions of the device model.
> 
> Of course, that only gives you a forward path.  It doesn't give you a 
> backwards path.

Why not? Just include the version in the rule set and define a backwards rule 
if it's easy to do. If not, migration isn't possible.


Alex