From: malc <av1474@comtv.ru>
To: Glauber Costa <glommer@redhat.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Main loop
Date: Mon, 28 Sep 2009 22:50:32 +0400 (MSD) [thread overview]
Message-ID: <Pine.LNX.4.64.0909282246530.2983@linmac.oyster.ru> (raw)
In-Reply-To: <20090928135723.GK29735@mothafucka.localdomain>
On Mon, 28 Sep 2009, Glauber Costa wrote:
> > > Glauber spent some time with the IO thread recently. Any reason you didn't
> > > start with the existing IO thread (besides the fact that it doesn't work with
> > > TCG)?
> > >
> >
> > Because i wasn't writing a replacement for IO Thread to begin with (btw it
> > does work with TCG), what it doesn't do is play nicely with icount[1],
> > work on Windows, and for mysterious reasons still requires alarm timers,
> > it also deadlocks for me when killing QEMU windows while running smp
> > guest, but that's easily corrected mistake somewhere i guess.
>
> You wasn't, but you ended up doing so, since it is unlikely that they
> will both live in the end. I am still reading your patch, and I still
> have to struggle a little bit to understand it. Can you please tell us
> why do you think your approach is better?
>
> The current I/O thread currently works with both kvm and tcg. For KVM, I
> am quite close (expecting to post patches today) that enables the
> in-kernel irqchip for it, and pretty close to do smp.
>
> Note that I don't think it requires alarm timers at all, by design. So,
> again, why should we drop what we have in favour of your implementation?
Now that we have talked i see the problem and it basically boils down
to this: kvm can(and does) run multiple vcpus in multiple threads,
qemu always uses one, on top of this you are mainly interested in KVM
and i'm _only_ interested in TCG. The way i see it the best approach
would be to factor out main loop into separate file and let QEMU and
KVM go their own separate ways w.r.t. this new entity.
--
mailto:av1474@comtv.ru
next prev parent reply other threads:[~2009-09-28 18:50 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-26 23:55 [Qemu-devel] Main loop malc
2009-09-27 0:49 ` Anthony Liguori
2009-09-27 10:55 ` malc
2009-09-27 14:05 ` Anthony Liguori
2009-09-27 14:39 ` malc
2009-09-28 13:57 ` Glauber Costa
2009-09-28 18:50 ` malc [this message]
2009-09-28 19:35 ` Anthony Liguori
2009-09-28 21:21 ` Glauber Costa
2009-09-28 23:57 ` malc
2009-09-27 14:31 ` malc
2009-09-27 14:23 ` Blue Swirl
2009-09-27 14:35 ` malc
2009-09-27 17:43 ` malc
[not found] ` <m3fxa7jug0.fsf@neno.mitica>
2009-09-28 9:42 ` [Qemu-devel] " malc
[not found] ` <m3pr9bidy9.fsf@neno.mitica>
2009-09-28 10:19 ` malc
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=Pine.LNX.4.64.0909282246530.2983@linmac.oyster.ru \
--to=av1474@comtv.ru \
--cc=glommer@redhat.com \
--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).