All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sheng Yang <sheng@linux.intel.com>
To: kvm@vger.kernel.org
Cc: Alexander Graf <agraf@suse.de>,
	Mohammed Gamal <m.gamal005@gmail.com>,
	Avi Kivity <avi@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: Completing big real mode emulation
Date: Wed, 24 Mar 2010 18:05:26 +0800	[thread overview]
Message-ID: <201003241805.26913.sheng@linux.intel.com> (raw)
In-Reply-To: <DF69E881-F8D0-4CE0-B12C-077B75B60634@suse.de>

On Saturday 20 March 2010 23:00:49 Alexander Graf wrote:
> 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.
> 
At least 10u2 installer has trouble. I had spent some time on it, finally 
found it's due to ISOLINUX.

The basic issue is it assume that SS selector/base is unchanged when 
enter/exit protect mode. At that time, I've cooked a hack workaround for it, 
but didn't think it's proper to upstream.

-- 
regards
Yang, Sheng

WARNING: multiple messages have this Message-ID (diff)
From: Sheng Yang <sheng@linux.intel.com>
To: kvm@vger.kernel.org
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Mohammed Gamal <m.gamal005@gmail.com>,
	Alexander Graf <agraf@suse.de>, Avi Kivity <avi@redhat.com>
Subject: [Qemu-devel] Re: Completing big real mode emulation
Date: Wed, 24 Mar 2010 18:05:26 +0800	[thread overview]
Message-ID: <201003241805.26913.sheng@linux.intel.com> (raw)
In-Reply-To: <DF69E881-F8D0-4CE0-B12C-077B75B60634@suse.de>

On Saturday 20 March 2010 23:00:49 Alexander Graf wrote:
> 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.
> 
At least 10u2 installer has trouble. I had spent some time on it, finally 
found it's due to ISOLINUX.

The basic issue is it assume that SS selector/base is unchanged when 
enter/exit protect mode. At that time, I've cooked a hack workaround for it, 
but didn't think it's proper to upstream.

-- 
regards
Yang, Sheng

  reply	other threads:[~2010-03-24 10:05 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-19 15:29 Completing big real mode emulation Mohammed Gamal
2010-03-19 15:29 ` [Qemu-devel] " Mohammed Gamal
2010-03-20  7:49 ` Avi Kivity
2010-03-20  7:49   ` [Qemu-devel] " Avi Kivity
2010-03-20  8:34   ` Alexander Graf
2010-03-20  8:34     ` [Qemu-devel] " Alexander Graf
2010-03-20  8:39     ` Avi Kivity
2010-03-20  8:39       ` [Qemu-devel] " Avi Kivity
2010-03-20  8:55       ` Alexander Graf
2010-03-20  8:55         ` [Qemu-devel] " Alexander Graf
2010-03-20 13:18         ` Avi Kivity
2010-03-20 13:18           ` [Qemu-devel] " Avi Kivity
2010-03-20 14:02           ` Mohammed Gamal
2010-03-20 14:02             ` [Qemu-devel] " Mohammed Gamal
2010-03-20 15:00             ` Alexander Graf
2010-03-20 15:00               ` [Qemu-devel] " Alexander Graf
2010-03-24 10:05               ` Sheng Yang [this message]
2010-03-24 10:05                 ` Sheng Yang
2010-03-24  0:39           ` Jamie Lokier
2010-03-24  0:39             ` Jamie Lokier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201003241805.26913.sheng@linux.intel.com \
    --to=sheng@linux.intel.com \
    --cc=agraf@suse.de \
    --cc=avi@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=m.gamal005@gmail.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.