On 11.04.2014, at 14:38, Alexey Kardashevskiy <address@hidden> 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?