Re: Completing big real mode emulation

Alexander Graf
2010-03-20T15:02:41Z

Am 20.03.2010 um 15:02 schrieb Mohammed Gamal <m.gamal005@gmail.com>:

> On Sat, Mar 20, 2010 at 3:18 PM, Avi Kivity <avi@redhat.com> wrote:
>> On 03/20/2010 10:55 AM, Alexander Graf wrote:
>>>>
>>>>> I'd say that a GSoC project would rather focus on making a guest
>>>>> OS work
>>>>> than working on generic big real mode. Having Windows 98 support
>>>>> is way more
>>>>> visible to the users. And hopefully more fun to implement too,
>>>>> as it's a
>>>>> visible goal :-).
>>>>>
>>>>>
>>>>
>>>> Big real mode allows you to boot various OSes, such as that old
>>>> Ubuntu/SuSE boot loader which triggered the whole thing.
>>>>
>>>
>>> I thought legacy Windows uses it too?
>>>
>>
>> IIRC even current Windows (last I checked was XP, but it's probably
>> true for
>> newer) invokes big real mode inadvertently. All it takes is not to
>> clear fs
>> and gs while switching to real mode. It works because the real
>> mode code
>> never uses gs and fs (i.e. while we are technically in big real
>> mode, the
>> guest never relies on this), and because there are enough hacks in
>> vmx.c to
>> make it work (restoring fs and gs after the switch back). IIRC
>> there are
>> other cases of invalid guest state that we hack into place during
>> mode
>> switches.
>>
>>> Either way - then we should make the goal of the project to
>>> support those
>>> old boot loaders. IMHO it should contain visibility. Doing
>>> theoretical stuff
>>> is just less fun for all parties. Or does that stuff work already?
>>>
>>
>> Mostly those old guests aged beyond usefulness. They are still
>> broken, but
>> nobody installs new images. Old images installed via workarounds
>> work.
>>
>> Goals for this task could include:
>>
>> - get those older guests working
>> - get emulate_invalid_guest_state=1 to work on all supported guests
>> - switch to emulate_invalid_guest_state=1 as the default
>> - drop the code supporting emulate_invalid_guest_state=0 eventually
>
> To this end I guess the next logical step is to compile a list of
> guests that are currently not working/work with hacks only, and get
> them working. Here are some suggestions:
> - MINIX 3.1.6 (developers have been recently filing bug reports
> because of boot failures)
> - Win XP with emulation enabled
> - FreeDOS with memory extenders
>
> Any other guests you'd like to see on this list?

I remember old openSUSE iso bootloaders had issues. I think it was
around 10.3, but might have been earlier.

Alex