[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH][QEMU] Fix HVM guest hang in save/restore with the network load
SUZUKI Kazuhiro writes ("Re: [Xen-devel] [PATCH][QEMU] Fix HVM guest hang in save/restore with the network load"): > I attach a new patch which saves only irq_state[] and calculates > irq_count[] by calling pci_set_irq(). > I also add version check code in pci_device_save()/load() for backward > compatibility. This patch isn't quite the one that was actually committed (c/s 17518) and I'm a bit late with this comment, but: > + qemu_get_buffer(f, (uint8_t*)irq_state, sizeof(int)*4); > + for (i = 0; i < 4; i++) > + pci_set_irq(s, i, irq_state[i]); qemu upstream have a different way of doing this: they save each irq_state[i] as a separate 32bit value (since December 2007): void pci_device_save(PCIDevice *s, QEMUFile *f) { ... for (i = 0; i < 4; i++) qemu_put_be32(f, s->irq_state[i]); } Is there some reason why we shouldn't do the same ? If we did then that would make our code here identical to upstream's and avoid another needless point of divergence. I assume that at this stage in xen-unstable we don't mind making a backward incompatible change to the saved image format ? If there's no reason not to synch with qemu here I will make a patch. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |