[Qemu-devel] Re: [PATCH] update bochs vbe interface

[Juan Quintela]

Gerd Hoffmann <address@hidden> wrote:
>   Hi,
>
>> Then our big problem is migration between read of the 1st register and
>> of the 2nd register, no?
>
> "big"? 

That is why I asked.  I have no clue about how many times that register
is read.

> The window is quite small, and I think we have a bunch of
> simliar issues elsewhere in qemu.  They are hardly avoidable for new
> -> 
> old migration when adding new features to emulated devices.

yeap, but normally we don't allow migration from new to old for this
very reason.  Not allowing from new to old fixes this issue.  Sections
can't help here :(

> Well, maybe sections can fix it, but probably only in case the old
> qemu is new enougth that it can handle sections too.

sections don't help here :(
We are changing how hardware works under the BIOS code, we told 1st that
we have a feature and when BIOS go to use it, feature has disappeared.

>> Furthermore, older vga bios, seing VBE_DISPI_ID5, what are they going to
>> do?
>
> Work as they did before ;)

/me just like BIOS :) 

>>>   So when migrating from new to old qemu:  Before reset
>>> vgabios will have the video memory size saved somewhere.  After reset
>>> ID will reset to ID0, and in case you are running vgabios 0.6c vesa
>>> gfx modes will stop working.
>>
>> I see this part, but I still think that we have a window where we can be
>> in very bad shape, no?  I guess that we don't support anything different
>> that vgabios, so ....
>
> See above.  Worst case is that vesa graphics modes stop working, even
> if you hit the race window (vgabios will think you have 0 MB video ram
> then and refuse all gfx modes).

If it is only read during startup, once, I think that geting 0 size is
ok.  Extra bonus for modifying vgabios to handle this case nicely?

Should be a case of

if (val == 0) {
   do like old bios
}

no?

Later, Juan.