Re: [Qemu-devel] [PATCH] pci.c: restore bus-level pci interrupt state via pci_set_irq

[Ian Jackson]

Ian Jackson writes ("[Qemu-devel] [PATCH] pci.c: restore bus-level pci 
interrupt state via pci_set_irq"):
> (This patch depends on my previous one which makes providing a save
> function to register_savevm optional.)
> 
>     pci.c: restore bus-level pci interrupt state via pci_set_irq
>     
>     This change abolishes pcibus_save.  Instead we use an invariant - that
>     device interrupts are supposed to be reflected in the bus interrupt
>     state - to restore the bus interrupt state.
>     
>     This makes the code smaller and removes one way in which a savefile
>     could be corrupted (eg, if it had been generated by a buggy emulator).
>     
>     It also means that systems which do some of their own PCI bus
>     emulation and thus reflect PCI bus state elsewhere (eg CPU acclerators
>     such as Xen) get notified of the PCI bus interrupt level, via
>     pci_set_irq's call to bus->set_irq.

Was there something wrong with this patch ?

I need a resolution to this because currently xen-unstable has a
different incompatible way of addressing the need I mention in my
final paragraph above.

I want to bring the two branches into line but that means I will need
a way to solve this situation in qemu.  If I can't get a suitable
conclusion here then it will be yet another useless divergence
(including another savefile format difference) between Xen qemu and
upstream.


I'm afraid I'm going to digress now rather, because my efforts to
submit patches here are leaving me quite frustrated:

I appreciate that the structure of Xen as a whole may not always be
the way the Qemu designers would have done, because Xen takes much
more responsibility for the overall management of the guest.  But I
think those are legitimate design choices, and I think it is quite
possible to maintain this difference in model without doing undue
violence to either Qemu or Xen.

Qemu already has nearly all of the internal APIs and interfaces
necessary to deal with the differences for the Xen case.  But we
really need those APIs to be used.  This example is of a very small
patch which changes Qemu to use those internal APIs where they apply,
and which has some minor benefits upstream, but is essential for Xen.

There are also several useful patches in our tree that you may wish to
have.  For example, we have patches to allow acceleration of guest
graphics operations by use of the host's SDL; I think these would be
quite compatible with Qemu mainline if it weren't for the fact that
the two trees are so diverged.  I am hoping to be able to bring our
trees close enough together that I can submit substantial new features
like that one here, and have them accepted.

I appreciate that in the past (before my time!) some of the things
that Xen did to their version of qemu were quite unpleasant.  Xen
hasn't always had a good record of keeping changes suitable for
upstream use where possible, and feeding patches upstream.

And I'm not saying that Qemu upstream should take all of the changes
to make Qemu work in the Xen HVM context.  We are prepared to continue
maintaining our own private branch.  But we would like to do this via
appropriate hooks and modularisation, or at the very least by keeping
the textual changes small.  We would like to keep our changes to the
minimum necessary, and to pass upstream everything that would be
useful to other users of Qemu.  That will allow work on bugfixes and
features to be shared.

I'm really trying to do a good and useful job here.  I appreciate that
I do, like anyone, sometimes make mistakes.  But I have to say that
I'm feeling rather discouraged by the difficulties I'm having getting
patches accepted upstream.

If the problem is simply lack of effort, for example a shortage of
committers with time on their hands, then I can certainly help.

Also, just to be clear, I don't see the kqemu, or kvm, as competing
with the Xen changes in this area.  Obviously they are competing
projects - which is healthy.  But that doesn't mean that we can
cooperate to try to make qemu have the right hooks so that all of our
use cases are readily supportable - and fast.

Ian.