From: Juergen Gross <juergen.gross@ts.fujitsu.com>
To: Jan Beulich <JBeulich@novell.com>
Cc: Daniel Castro <evil.dani@gmail.com>,
xen-devel@lists.xensource.com, seabios@seabios.org
Subject: Re: Ideas for PV on SeaBIOS
Date: Thu, 19 May 2011 10:17:17 +0200 [thread overview]
Message-ID: <4DD4D20D.9090500@ts.fujitsu.com> (raw)
In-Reply-To: <4DD4EC2502000078000420F7@vpn.id2.novell.com>
On 05/19/11 10:08, Jan Beulich wrote:
>>>> On 19.05.11 at 07:33, Daniel Castro<evil.dani@gmail.com> wrote:
>> In order to give PV Drivers to SeaBIOS we will need to solve a few
>> problems, one is the following:
>> Does a booting kernel informs the BIOS that it will leave real mode
>> and not use it again? When the booting kernel uses CPU real mode for
>> the last time, how can we (Xen or SeaBIOS) know that real mode will no
>> longer be used, and hence BIOS calls will not be issued?
>> We want upon last real mode usage to leave all Xen PV information in a
>> clean state, this means, closing the channel and ring between the
>> newly created domain and the host system.
> How can you be certain an OS won't switch back to real mode even
> after an extended period of up-time? Or that such switching back
> would affect you (could be calling e.g. the video or PCI BIOS
> functions only).
>
> There is INT15 AX=EC00 with BX specifying the target operating
> mode, but that's apparently being called only before entering
> long mode (i.e. wouldn't cover 32-bit OSes). And it would neither
> be a guarantee that the OS might not later return to real mode.
Wouldn't it be possible for the BIOS to reestablish the connection to Xen
in this case? This might be the best solution: close the channel and ring
at some specific event (might even be timer based) and open them again
if really needed.
Juergen
--
Juergen Gross Principal Developer Operating Systems
TSP ES&S SWE OS6 Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions e-mail: juergen.gross@ts.fujitsu.com
Domagkstr. 28 Internet: ts.fujitsu.com
D-80807 Muenchen Company details: ts.fujitsu.com/imprint.html
next prev parent reply other threads:[~2011-05-19 8:17 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-19 5:33 Ideas for PV on SeaBIOS Daniel Castro
2011-05-19 7:19 ` Keir Fraser
2011-05-19 8:01 ` [Xen-devel] " Ian Campbell
2011-05-21 7:39 ` Paolo Bonzini
2011-05-21 8:44 ` James Harper
2011-05-23 9:23 ` [Xen-devel] " Ian Campbell
2011-05-23 10:20 ` James Harper
2011-05-23 10:23 ` Ian Campbell
2011-05-19 7:44 ` James Harper
2011-05-19 8:08 ` Jan Beulich
2011-05-19 8:17 ` Juergen Gross [this message]
2011-05-19 8:20 ` Tim Deegan
2011-05-19 9:36 ` Ian Campbell
2011-05-19 15:02 ` Keir Fraser
2011-05-19 17:00 ` Ideas for PV on SeaBIOS - flush/barrier in QEMU Konrad Rzeszutek Wilk
2011-05-19 9:32 ` Ideas for PV on SeaBIOS James Harper
2011-05-21 13:38 ` [SeaBIOS] " Kevin O'Connor
2011-05-21 13:29 ` Kevin O'Connor
2011-05-23 5:24 ` Stefan Hajnoczi
2011-05-23 9:50 ` Ian Campbell
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=4DD4D20D.9090500@ts.fujitsu.com \
--to=juergen.gross@ts.fujitsu.com \
--cc=JBeulich@novell.com \
--cc=evil.dani@gmail.com \
--cc=seabios@seabios.org \
--cc=xen-devel@lists.xensource.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).