From: Avi Kivity <avi@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Chris Wright <chrisw@redhat.com>, Jan Kiszka <jan.kiszka@web.de>,
qemu-devel@nongnu.org, kvm@vger.kernel.org
Subject: [Qemu-devel] Re: KVM call agenda for Mar 23
Date: Tue, 23 Mar 2010 14:51:32 +0200 [thread overview]
Message-ID: <4BA8B954.8010907@redhat.com> (raw)
In-Reply-To: <4BA8B7FB.2050103@codemonkey.ws>
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
next prev parent reply other threads:[~2010-03-23 12:51 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-23 6:11 [Qemu-devel] KVM call agenda for Mar 23 Chris Wright
2010-03-23 8:40 ` [Qemu-devel] " Juan Quintela
2010-03-23 13:25 ` Juan Quintela
2010-03-23 9:31 ` Jan Kiszka
2010-03-23 9:52 ` Avi Kivity
2010-03-23 10:50 ` Jan Kiszka
2010-03-23 10:57 ` Avi Kivity
2010-03-23 11:13 ` Jan Kiszka
2010-03-23 12:29 ` Avi Kivity
2010-03-23 12:45 ` Anthony Liguori
2010-03-23 12:51 ` Avi Kivity [this message]
2010-03-23 12:56 ` Jes Sorensen
2010-03-25 1:31 ` Zhang, Xiantao
2010-03-25 9:39 ` Jan Kiszka
2010-03-25 9:43 ` Jes Sorensen
2010-03-26 18:48 ` Chris Wright
2010-03-23 12:40 ` Anthony Liguori
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4BA8B954.8010907@redhat.com \
--to=avi@redhat.com \
--cc=anthony@codemonkey.ws \
--cc=chrisw@redhat.com \
--cc=jan.kiszka@web.de \
--cc=kvm@vger.kernel.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).