On Fri, Jun 01, 2012 at 05:15:42PM +0200, Jan Kiszka wrote: > On 2012-06-01 16:34, Michael S. Tsirkin wrote: > > On Fri, Jun 01, 2012 at 03:57:01PM +0200, Jan Kiszka wrote: > >> On 2012-06-01 15:27, Michael S. Tsirkin wrote: > >>> On Fri, Jun 01, 2012 at 02:52:56PM +0200, Jan Kiszka wrote: > >>>> On 2012-05-30 22:31, Michael S. Tsirkin wrote: > >>>>>>> So we'll just have PIIX_NUM_PIC_IRQS entries there and use > >>>>>>> irq_count instead of the pic_levels bitmap. > >>>>>> > >>>>>> Just that this affects generic PCI code, not only PIIX-specific things. > >>>>> > >>>>> Yes but it's not a problem - pci_bus_irqs sets the map function and > >>>>> nirqs. > >>>>> > >>>>>> And that we need to save/restore some irq_count field according to the > >>>>>> old semantics. > >>>>> > >>>>> Well, it's a bug: this is redundant info we should not have exposed it. > >>>>> > >>>>> Anyway, let's make the rest work properly and cleanly first, add a FIXME > >>>>> for now, then we'll find a hack making it work for migration. > >>>> > >>>> It remains non-trivial: I got your patch working (a minor init issue), > >>>> but yet without changing the number of IRQs for PIIX3, so keeping the > >>>> irq_count semantics for this host bridge. > >>>> > >>>> Now I'm facing three possibilities of how to proceed: > >>> > >>> They all look OK I think :) Some comments below. > >>> > >>>> 1. Give up on the (currently broken) feature to write a vmstate for > >>>> older QEMU versions. > >>>> > >>>> This will allow to declare the irq_count field in vmstate_pcibus > >>>> unused, and we would have to restore it on vmload step-wise via the > >>>> PCI devices. It would also allow to change its semantics for PIIX3, > >>>> mapping directly to PIC IRQs. > >>> > >>> I think that's okay too simply because these things are usually > >>> easy to fix after the fact when the rest of the issues are addressed. > >> > >> Don't get what you mean with "fixed". If we fix the vmstate generation > >> in making it backward-compatible again, we enter option 2. Option 1 is > >> explicitly about giving this up. > > > > What I really mean is I think I see how 2 can be added without much > > pain. So let's focus on 1 for now and worst case we break migration. > > I'd like to avoid planing for this worst case as long as there are also > statements [1] that this is not acceptable for QEMU in general. It > doesn't to create a beautiful architecture initially about which we > already know that it will become more complex than alternatives in the end.
1 and 2 are same really except 2 adds a hack for compatibility, no?
