RE: [Xen-devel] real-mode switch

["Jan Beulich" <jbeulich@xxxxxxxxxx>]

As I said in my reply - this is exactly the one thing missing so far. But it 
ought
to be done in Xen, not in dom0, and it is on my todo list. Jan

>>> "Jayant Mangalampalli" <Jayant_Mangalampalli@xxxxxxxxxxx> 06.06.07 12:32 >>>
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