"Michael S. Tsirkin" <m...@redhat.com> wrote: > On Wed, Nov 19, 2014 at 10:19:22AM +0100, Juan Quintela wrote:
>> >> I very much prefer to have >> >> user-controlled ACPI information (coming from the command-line) >> >> byte-for-byte identical for a given machine type. Patches for that have >> >> been on the list for almost two months, and it's not nice. >> >> >> >> Paolo >> > >> > I guess we just disagree on whether these patches will effectively achieve >> > this goal. For example, some people want to rewrite iasl bits, >> > generating everything in C. This will affect static bits too. >> > I don't want to make every single change in code conditional >> > on a machine type. >> >> You can't migrate with a different BIOS on destination, period. > > This claim is very wrong. > This would make is impossible to change BIOS bus without breaking > migration. Look at history of qemu, we change BIOS every release. And we should do: qemu -M pc-2.0 -L BIOS-2.0.bin And that way for every version and every bios. If they are the same, a symlink does. If they are not, different file. And we would not have this problems. I fully agree that we have problems with BIOS every relase. What we don't agree is _what_ is the best way to fix the issue. >> IMHO, b) is just asking for trouble. Being able to go from random >> changes to random changes look strange. > > Yes, it is hard to support. > But it's a required feature, and in fact, it's an existing one. >> Just think about it for a second. We are sending more data for some >> regions that it was allocated. And we just grow the regions and expect >> that everything is going to be ok. It is me, or this goes against every >> security discipline that I can think of? >> >> Later, Juan. > > We have many devices that just get N from stream, do malloc(N), then read > data from stream into it. > You think it's unsafe? Go ahead and fix them all. I am sure it is unsafe. Fixing them requires incompatible changes, that is the whole point :-( > However, my patch does address your concern: callers specify the upper > limit on the region size. > Trying to migrate in a 1Gbyte region Yes and no. You are assuming that a guest launched with a device ram size of 256KB receives a 512KB section and it knows what to do with it. It knows what to do with the 256KB section, with the 512KB answer is always a "perhaps". It depends of what is on the extra space. My solution would be that RAM/ROM sizes are always the same for migration, so destination would always understand it. It just forbids migrating between different machine types. And I think that is good, not bad. Later, Juan.
