All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.