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

[Anthony Liguori]

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.

Regards,

Anthony Liguori