On 04/11/2014 11:58 PM, Alexander Graf wrote: > > On 11.04.2014, at 14:38, Alexey Kardashevskiy <a...@ozlabs.ru> wrote: > >> On 04/11/2014 07:24 PM, Alexander Graf wrote: >>> >>> On 10.04.14 16:43, Alexey Kardashevskiy wrote: >>>> On 04/10/2014 11:26 PM, Alexander Graf wrote: >>>>> On 10.04.14 15:24, Alexey Kardashevskiy wrote: >>>>>> On 04/10/2014 10:51 PM, Alexander Graf wrote: >>>>>>> On 14.03.14 05:18, Alexey Kardashevskiy wrote: >>>>>>>> The current allocator returns IRQ numbers from a pool and does not >>>>>>>> support IRQs reuse in any form as it did not keep track of what it >>>>>>>> previously returned, it only had the last returned IRQ. >>>>>>>> However migration may change interrupts for devices depending on >>>>>>>> their order in the command line. >>>>>>> Wtf? Nonono, this sounds very bogus and wrong. Migration shouldn't >>>>>>> change >>>>>>> anything. >>>>>> I put wrong commit message. By change I meant that the default state >>>>>> before >>>>>> the destination guest started accepting migration is different from what >>>>>> the destination guest became after migration finished. And migration >>>>>> cannot >>>>>> avoid changing this default state. >>>>> Ok, why is the IRQ configuration different? >>>> Because QEMU creates devices in the order as in the command line, and >>>> libvirt changes this order - the XML used to create the guest and the XML >>>> which is sends during migration are different. libvirt thinks it is ok >>>> while it keeps @reg property for (for example) spapr-vscsi devices but it >>>> is not because since the order is different, devices call IRQ allocator in >>>> different order and get different IRQs. >>> >>> So your patch migrates the current IRQ configuration, but once you restart >>> the virtual machine on the destination host it will have different IRQ >>> numbering again, right? >> >> No, why? IRQs are assigned at init time from realize() callbacks (and >> survive reset) or as a part of ibm,change-msi rtas call which happens in >> the same order as it only depends on pci addresses and we do not change >> this either. >
> Ok, let me rephrase. If I shut the machine down because I'm doing > on-disk hibernate and then boot it back up, will the guest find the same > configuration? I do not understand what you mean by this. Hibernation by the guest OS itself or by QEMU? If this involves QEMU exit and QEMU start - then yes, config may be different. If it is "migrate to file" and then "migrate from file" (do not know what you call it when migration goes to a pipe which is "tar") - then config will be the same. >>> I'm not sure that's a good solution to the problem. I guess we should >>> rather aim to make sure that we can make IRQ allocation explicit. >>> Fundamentally the problem sounds very similar to the PCI slot allocation >>> which eventually got solved by libvirt specifying the slots manually. >> >> We can do that too. Who decides? :) > > The better solution wins :) We both know who decides ;) I posted series, I need heads up if it is going the right way or not. -- Alexey
