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

[Avi Kivity]

On 01/11/2011 05:55 PM, Anthony Liguori wrote:
> > > 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.
> >
> > It would be easier to have them use the same device id in the first 
> > place.
> >
> > If it looks like an i8254, quacks like an i8254, and live migrates 
> > like an i8254, it's probably an i8254.
>
> And that's fine.  I'm not suggesting you call it i8253.  But it's two 
> separate implementations.  We should make that visible, not try to 
> hide it.  It's an important detail.

Visible, yes, but not in live migration, or in 'info i8254', or 
similar.  We can live migrate between qcow2 and qed (using block 
migration), we should be able to do the same for the two i8254 
implementations.

I'm not happy about separate implementations, but that's a minor 
details.  We can change it 2n+1 times without anybody noticing.  Not so 
about ABI stuff.

> Imagine getting a sosreport that includes a dump of the device tree.  
> You really want to see something in there that tells you it's an 
> in-kernel PIT and not the userspace one.

Sure.  Not the device tree though.  The command line would give all the 
information?

Or 'info i8254' can say something about the implementation.  I don't 
want to have the user say 'info i8254-kvm'.