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'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 :) Alex
