| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] real-mode switch
The problem traces back to setting appropriate vesa mode after xen
initialization is done. For that we need an ability to get into real
mode briefly and we can set the mode back to 'protected' after the vesa
driver setting is done.
-----Original Message-----
From: Keir Fraser [mailto:keir@xxxxxxxxxxxxx]
Sent: Wednesday, June 06, 2007 2:18 PM
To: Jan Beulich; Jayant Mangalampalli
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] real-mode switch
On 6/6/07 08:08, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:
> The problems with real mode code execution after initial boot is that
once
> interrupts and certain types of exceptions got enabled, they would
need
> to be masked over an unbounded time period, risking either losing of
them
> or failing to handle them in time. On SMP systems, this would include
either
> halting all remote CPUs or gracefully dealing with IPIs that may be
sent
> against the CPU switching to or being in real mode (again over an
> unbounded period of time).
Also, it is usual to execute BIOS calls with interrupts enabled. That's
obviously bogus if protected-mode drivers have taken over devices,
interrupt
vectors have been remapped, etc.
So we're going to return to real mode only at beginning of Xen
execution,
and then down the road we'll come up with a scheme to avoid needing to
do
that in cases like kexec of Xen (if anyone cares).
-- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home