[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.