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
