Re: [PATCH v2 3/9] provide in-kernel ioapic

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jamie Lokier <jamie@xxxxxxxxxxxxx> 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.
--
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

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux