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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
