On Wed, Nov 19, 2014 at 11:45:15AM +0100, Juan Quintela wrote: > "Michael S. Tsirkin" <m...@redhat.com> wrote: > > On Wed, Nov 19, 2014 at 11:11:26AM +0100, Juan Quintela wrote: > >> "Michael S. Tsirkin" <m...@redhat.com> wrote: > >> > On Wed, Nov 19, 2014 at 10:19:22AM +0100, Juan Quintela wrote: > > > >> 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. > > > > You want to keep old bios around forever, and never fix > > bugs in it? I disagree, quite strongly. > > One thing is fix bugs, and a different one is completely change the way > the tables/data are generated.
I want the ability to do both without keeping a ton of old code around. > About keeping old bios forever, no. Only while the machine types that > depend on that BIOS are supported. At the very point that they get not > supported, we can drop it. Still too much. This is unsupportable and is not what we did historically. > > > >> > >> 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. > >> > > > > > > You don't seem to want to fix them. Your solution is just to keep > > bugs around forver. > > That is unfair. It is the same that if I answer that your solution is > just paper over the bugs that we have already foound and hope that there > are no more bugs. Do you think that describes your position? Mine is > also not described but your statement. Then I don't understand. How do you suggest fixing BIOS bugs without changing BIOS? People have legitimate reasons to run compat machine types, and they also need bugs fixed. > >> > 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 :-( > > > > I don't see the point, sorry. Want to elaborate? > > In general, I don't have specific examples: > - when we have a string buffer, we sent/receive it with: > > VMSTATE_BUFFER(queue.data, PS2State), > > We are sending whatever the size of queue.data is on source to whatever > the queue.data is on destination. We are hopping that they are the > same. > > In this case, if sizes are different, we got just a migration stream > that is out of sync. And if attacker modifies stream, bad things could > happen. > In the case of buffers/arrays (so far it appears that everyplace that > recives a size from the network, it checks that it is small enough). > > > > >> > 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. > > > > You basically ask firmware to be perfect, or want us to carry old bugs > > around forever. It makes things simple for migration code, at huge cost > > elsewhere, and pain for users. > > > > I don't want to maintain old bugs in ACPI, and same applies to > > other firmware. > > > > This is really the whole point of the patchset. > > Keep bugs in device ram around until next reboot. > > At that point users get new device with non buggy > > behaviour. > > False. > > qemu-2.2 -M pc-2.0 -> qemu-2.0 -M pc-2.0 > > You migrate that way, and you go from "new-good" BIOS to "bad-old" BIOS. So? What is the point? > I think the question here is, when we do this migration: > > qemu-2.0 -M pc-2.0 -> qemu-2.2 -M pc-2.0 > > what BIOS should the second qemu use? the one that existed on qemu-2.0 > time or the one that existed on qemu-2.2 time? You can allow for > bugfixes, but not for big changes like moving where the acpi tables were > generated, etc, etc. If you just ship old BIOS, you do not allow for bugfixes. > I really think that we should use the BIOS from qemu-2.0 era. And my > understanding is that you defend that we should use the qemu-2.2 era > BIOS. Not only that. We already do. And we don't intend to change that for 2.2. > I think that is the whole point of the discussion. Have I at least > framed correctly what the discussion is about? > > Later, Juan. I think so. Basically you want to freeze all firmware at time of release and never change it for that machine type. Correct? This would be a regression, this is not how we did things in the past. Real hardware lets users update firmware and so should virtual hardware. -- MST
