[Qemu-devel] Re: KVM call agenda for Mar 23

[Avi Kivity]

On 03/23/2010 02:45 PM, Anthony Liguori wrote:
> On 03/23/2010 04:52 AM, Avi Kivity wrote:
> > On 03/23/2010 11:31 AM, Jan Kiszka wrote:
> > > Chris Wright wrote:
> > > > Please send in any agenda items you are interested in covering.
> > > >
> > > > Yes, usability is a valid topic esp. if you promise to come w/ GUI 
> > > > patches.
> > > - state and roadmap for upstream merge of in-kernel device models
> > >    (looks to me like this central merge effort is stalled ATM)
> >
> > - alternative path of merging qemu-kvm.git's implementation as is and 
> > cleaning it up in qemu.git.
> >
> > For kvm.git, I wouldn't dream of merging something with outstanding 
> > issues and cleaning them up "later", but the situation is somewhat 
> > different with qemu vs qemu-kvm.
>
> I don't think we can pull in:
>
>  - extboot
>  - ia64
>  - in-kernel pit[1]
>  - associated command line options
>  - device passthrough

I'm not proposing these for merge, except [1].

> The question is, if we dropped those things, would people actually use 
> qemu.git instead of qemu-kvm.git.  If the answer is "no", what set of 
> things do we need in order for people to focus on qemu.git instead of 
> qemu-kvm.git.

Device passthrough is sufficiently obscure that most people could use 
qemu.git (not distributions, though).  ia64 is dead.  Command line 
options would need to be cleaned up.  We'd need an extboot replacement, 
people do boot from virtio.

> [1] I'd like to revisit this discussion.  We originally went the 
> in-kernel pit route because of difficulties changing qemu.  That's a 
> bad reason to put something in the kernel.  I'd prefer to see us fix 
> qemu.  After that, we can look at in-kernel pit and see if there are 
> any remaining advantages (like performance).  If it's significant, we 
> can still merge in-kernel pit.

The reason was drift compensation IIRC.  Also, some guests read the time 
back from the PIT.  Perhaps that's no longer the case with hpet enabled 
by default.

Drift compensation can be done in qemu by exposing ack notifiers to 
userspace; that's also needed for rtc drift compensation for Windows.

--
error compiling committee.c: too many arguments to function