All of lore.kernel.org
 help / color / mirror / Atom feed
From: Juan Quintela <quintela@trasno.org>
To: Jamie Lokier <jamie@shareable.org>
Cc: Glauber Costa <glommer@redhat.com>,
	kvm-devel <kvm@vger.kernel.org>,
	Anthony Liguori <aliguori@us.ibm.com>,
	Avi Kivity <avi@redhat.com>, Gleb Natapov <gleb@redhat.com>,
	qemu-devel@nongnu.org
Subject: Re: [PATCH v2 3/9] provide in-kernel ioapic
Date: Fri, 09 Oct 2009 21:55:13 +0200	[thread overview]
Message-ID: <m31vlctk9q.fsf@neno.mitica> (raw)
In-Reply-To: <20091009164955.GC7393@shareable.org> (Jamie Lokier's message of "Fri, 9 Oct 2009 17:49:55 +0100")

Jamie Lokier <jamie@shareable.org> wrote:
> Glauber Costa wrote:
>> On Thu, Oct 08, 2009 at 06:22:48PM +0200, Gleb Natapov wrote:
>> > On Thu, Oct 08, 2009 at 06:17:57PM +0200, Avi Kivity wrote:
>> > > On 10/08/2009 06:07 PM, Jamie Lokier wrote:
>> > > >Haven't we already confirmed that it *isn't* just an ioapic accelerator
>> > > >because you can't migrate between in-kernel iopic and qemu's ioapic?
>> > > 
>> > > We haven't confirmed it.  Both implement the same spec, and if you
>> > > can't migrate between them, one of them has a bug (for example, qemu
>> > > ioapic doesn't implement polarity - but it's still just a bug).
>> > > 
>> > Are you saying that HW spec (that only describes software visible behavior)
>> > completely defines implementation? No other internal state is needed
>> > that may be done differently by different implementations?
>> Most specifications leaves a lot as implementation specific.
>> 
>> It's not hard to imagine a case in which both devices will follow
>> the spec correctly, (no bugs involved), and yet differ in the
>> implementation.
>
> Avi's not saying the implementations won't differ.  I believe he's
> saying that implementation-specific states don't need to be saved if
> they have no effect on guest visible behaviour.

Just to re-state.  I would also prefer to have a single device.  Reasons
(majority already told in the thread):
- We can switch between devices more easily
- They are emulating the same device.
- At the moment that you have two different devices, one of them will
  rot :(
- Adding state to the save/load format that is used only from one device
  is not a problem.

I notice that discussion is going nowhere, basically we are in the
state:
- people that want one device
  * they emulate the same hardware
  * lots of code is shared
  * they should be interchageable
  * if they are not interchageable, it is a bug
  * once that they are split, it is basically imposible to join then
    again.
- people that want 2 devices:
  * The devices can more easily diverge if they are two devices
  * They are not interchageable now
  * It allows you more freedom in changing any of them if they are
    separate.

As you can see, none of the proposals is a clear winner.  And what is
worse, we have the two maintainers (avi and anthony), the two with more
experience having to deal with this kind of situation disagreeing.

How to fix the impass?

Later, Juan.

  reply	other threads:[~2009-10-09 19:56 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1254953315-5761-1-git-send-email-glommer@redhat.com>
     [not found] ` <1254953315-5761-2-git-send-email-glommer@redhat.com>
     [not found]   ` <1254953315-5761-3-git-send-email-glommer@redhat.com>
     [not found]     ` <1254953315-5761-4-git-send-email-glommer@redhat.com>
2009-10-08 13:49       ` [PATCH v2 3/9] provide in-kernel ioapic Anthony Liguori
2009-10-08 13:54         ` Avi Kivity
2009-10-08 15:53           ` Jan Kiszka
2009-10-08 16:07           ` [Qemu-devel] " Jamie Lokier
2009-10-08 16:12             ` Anthony Liguori
2009-10-08 16:17             ` Avi Kivity
2009-10-08 16:22               ` Gleb Natapov
2009-10-08 16:29                 ` Avi Kivity
2009-10-08 16:34                   ` Gleb Natapov
2009-10-08 16:42                     ` Avi Kivity
2009-10-08 17:11                       ` Gleb Natapov
2009-10-09 10:02                         ` Jamie Lokier
2009-10-09 12:02                           ` [Qemu-devel] " Gleb Natapov
2009-10-09 14:32                 ` Glauber Costa
2009-10-09 16:49                   ` [Qemu-devel] " Jamie Lokier
2009-10-09 19:55                     ` Juan Quintela [this message]
2009-10-09 21:34                       ` Glauber Costa
2009-10-12 13:20                       ` Anthony Liguori
2009-10-12 14:18                         ` Jamie Lokier
2009-10-12 14:49                           ` Anthony Liguori
     [not found]       ` <1254953315-5761-5-git-send-email-glommer@redhat.com>
2009-10-08 13:55         ` [PATCH v2 4/9] provide in-kernel apic Anthony Liguori
2009-10-08 14:09           ` Avi Kivity
2009-10-08 14:22             ` [Qemu-devel] " Glauber Costa
2009-10-09 10:06               ` Jamie Lokier
2009-10-09 14:30                 ` Glauber Costa
2009-10-09 16:48                   ` [Qemu-devel] " Jamie Lokier
2009-10-09 18:06                     ` Glauber Costa
2009-10-09 19:49                     ` [Qemu-devel] " Anthony Liguori
2009-10-11  9:10                       ` Avi Kivity
2009-10-12 13:41                         ` [Qemu-devel] " Anthony Liguori
2009-10-08 14:26             ` Anthony Liguori
2009-10-08 14:31               ` Avi Kivity
2009-10-08 14:39                 ` Anthony Liguori
2009-10-08 14:46                   ` Glauber Costa
2009-10-08 14:44                 ` Glauber Costa

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=m31vlctk9q.fsf@neno.mitica \
    --to=quintela@trasno.org \
    --cc=aliguori@us.ibm.com \
    --cc=avi@redhat.com \
    --cc=gleb@redhat.com \
    --cc=glommer@redhat.com \
    --cc=jamie@shareable.org \
    --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 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.