WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH][QEMU] Fix HVM guest hang in save/restore with th

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