Doug Goldstein <cardoe@xxxxxxxxxx> wrote: > On Sun, Nov 4, 2012 at 3:51 PM, Anthony Liguori <anthony@xxxxxxxxxxxxx> wrote: >>> >>> Seems reasonable. Doug, please verify to see if it's the same issue or >>> another one. >>> >>> Juan, how can we fix this? It's clear that the option ROM size has to >>> be fixed and not change whenever the blob is updated. This will fix it >>> for future releases. But what to do about the ones in the field? >> >> This is not a problem upstream because we don't alter the ROMs. If we >> did, we would keep the old ROMs around and set the romfile property in >> the compatible machine. >> >> This is what distros that are shipping ROMs outside of QEMU ought to >> do. It's a bug to unconditionally change the ROMs (in a guest visible >> way) without adding compatibility support. >> >> Regards, >> >> Anthony Liguori >> > > Anthony, > > Gerd updated seabios on August 7th and before that on April 17. The > default VGA ROM size also changed in recent releases. There are no old > versions of the ROMs included once these updates are performed so a > user building a new version from source will hit this problem. Juan > Quintela even mentioned that he has been bit by this issue and had to > use gdb to track it down as did Philipp that responded earlier in the > thread. The patch is a simple fprintf() which would have saved at > least 3 users the effort of tracking down an issue with gdb. So I urge > you to reconsider. I hit this problem. But it was a bug, the problem was to detect it. The problem was doing migration to an old version, we now "round" the RAM amount to a multiple of 8k. If your old ram memory was mulitple of 4k, you get this prolbem with migration. And it only prints "migration failed". Printing a message telling that: memory size of %foo is %d and expected %d would have make error trivial to found. Later, Juan. PD. Problem was really a bit more complex than this, this is a simplification. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html