RE: beginnings of allowing more than the basic 80x25 VGAscreen resolution

RE: beginnings of allowing more than the basic 80x25 VGAscreen resolution

[Ling, Xiaofeng]

Is it possible to add some real mode code to xen  like video.S in linux kernel 
to switch mode?
If dom0 can support vesa frame buffer driver, not only we can get 
more line in text console, but also we can use other application 
that can use frame buffer driver like SDL library. 
So a vmx guest graphic device model can run without X server.


Keir Fraser <> wrote:
> On 4 Jul 2005, at 09:00, Jan Beulich wrote:
> 
>> As far as I know, not only the VGA driver does not do any mode
>> switching, even the VESA one doesn't (because the protected mode
>> interface doesn't cover the mode switching functions as far as I
>> remember). Only the video board specific frame buffer drivers are
>> able to switch modes, and the bad thing (for me personally) is that
>> even in 
>> 2.6.12 there still is no (64-bit) support for the i915 chipset. So I
>> continue to be required to live with the video mode that XEN 'sets'
>> prior to loading dom0, and short of it supporting a VESA console my
>> first minimal attempt was to at least increase (and propagate) the
>> size to the maximum possible without significant changes.
> 
> That's a pain. Maybe we can find a simple example somewhere of
> setting video mode via protect-mode VBE calls. I see that this
> functionality is missing from the kernel drivers -- it's all done in
> a monstrous real-mode assembly file. Any video card we care about
> these days should support VBE 2.0/3.0 I think, and those interfaces
> don;t require you to be runnign in real mode.     
> 
>   -- Keir
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: beginnings of allowing more than the basic 80x25 VGAscreen resolution

[Gerd Knorr]

"Ling, Xiaofeng" <xiaofeng.ling@intel.com> writes:

> Is it possible to add some real mode code to xen  like video.S in linux kernel 
> to switch mode?

Hmm, how about adding that to the boot loader(s)?

IIRC there are some fields in the multiboot info header for that kind
of stuff, so grub could setup that and pass on the info to xen (and
xen in turn to the dom0 kernel?).

multiboot kernels are started in 32-bit protected mode by the boot
loader, i.e. xen has (unlike linux) no 16-bit startup code.  Thus
doing 16-bit BIOS calls once xen is running is a bit difficuilt ...

  Gerd

-- 
panic("it works"); /* avoid being flooded with debug messages */

Re: beginnings of allowing more than the basic 80x25 VGAscreen resolution

[Keir Fraser]

On 5 Jul 2005, at 13:58, Gerd Knorr wrote:

> IIRC there are some fields in the multiboot info header for that kind
> of stuff, so grub could setup that and pass on the info to xen (and
> xen in turn to the dom0 kernel?).
>
> multiboot kernels are started in 32-bit protected mode by the boot
> loader, i.e. xen has (unlike linux) no 16-bit startup code.  Thus
> doing 16-bit BIOS calls once xen is running is a bit difficuilt ...

GRUB has code for switching back into real mode to do bios calls. We 
could take that, plus video.S, and put them in Xen. Then add an info 
structure for passing video info up to domain0. It's pretty ugly, but I 
think there is no nice solution here. Would we also need vesa/vga 
driver code from Linux for setting up font data in some graphics modes?

  -- Keir

Re: beginnings of allowing more than the basic 80x25 VGAscreen resolution

[Jan Beulich]

>> IIRC there are some fields in the multiboot info header for that
kind
>> of stuff, so grub could setup that and pass on the info to xen (and
>> xen in turn to the dom0 kernel?).
>>
>> multiboot kernels are started in 32-bit protected mode by the boot
>> loader, i.e. xen has (unlike linux) no 16-bit startup code.  Thus
>> doing 16-bit BIOS calls once xen is running is a bit difficuilt ...
>
>GRUB has code for switching back into real mode to do bios calls. We 
>could take that, plus video.S, and put them in Xen. Then add an info 
>structure for passing video info up to domain0. It's pretty ugly, but
I 
>think there is no nice solution here. Would we also need vesa/vga 
>driver code from Linux for setting up font data in some graphics
modes?

Yes that would clearly be necessary, but perhaps a much more
streamlined mechanism would do for XEN.

Jan

Re: beginnings of allowing more than the basic 80x25 VGAscreen resolution

[Keir Fraser]

On 5 Jul 2005, at 14:22, Jan Beulich wrote:

>> GRUB has code for switching back into real mode to do bios calls. We
>> could take that, plus video.S, and put them in Xen. Then add an info
>> structure for passing video info up to domain0. It's pretty ugly, but
> I
>> think there is no nice solution here. Would we also need vesa/vga
>> driver code from Linux for setting up font data in some graphics
> modes?
>
> Yes that would clearly be necessary, but perhaps a much more
> streamlined mechanism would do for XEN.

If that's the case, I'm sure Gerd can point out the 'moving parts' that 
we actually need to get basic text output working. I was hoping video.S 
alone would be sufficient... :-)

  -- Keir

Re: beginnings of allowing more than the basic 80x25 VGAscreen resolution

[Gerd Knorr]

On Tue, Jul 05, 2005 at 02:28:27PM +0100, Keir Fraser wrote:
> 
> On 5 Jul 2005, at 14:22, Jan Beulich wrote:
> 
> >>GRUB has code for switching back into real mode to do bios calls. We
> >>could take that, plus video.S, and put them in Xen. Then add an info
> >>structure for passing video info up to domain0. It's pretty ugly, but
> >>I think there is no nice solution here.

Well, I'd simply leave that job completely to grub as it has to
deal with that anyway and the multiboot spec have fields to pass
on that info to the booted kernel.  Xen would simply take that
and pass it on to the Dom0 kernel, thats it.  And maybe adjust
it's own row/column counts in case it's vga text mode.

> >> Would we also need vesa/vga
> >>driver code from Linux for setting up font data in some graphics
> >modes?
> >
> >Yes that would clearly be necessary, but perhaps a much more
> >streamlined mechanism would do for XEN.
> 
> If that's the case, I'm sure Gerd can point out the 'moving parts' that 
> we actually need to get basic text output working. I was hoping video.S 
> alone would be sufficient... :-)

Text mode is really simple, that is just another screen size
than 80x25, but completely identical otherwise.  Font stuff is
handled by bios and vga hardware, nothing to worry about here.

In graphics mode you simply have a linear frame buffer and
you'll have to do everything yourself.  Linux has compiled-in
fonts for that.  Quite alot of stuff from drivers/video would
be needed to get that going in xen, but I wouldn't even try to
make xen render text in graphics mode and leave that completely
to the dom0 kernel ...

  Gerd

Re: beginnings of allowing more than the basic 80x25 VGAscreen resolution

[Jan Beulich]

>>> Gerd Knorr <kraxel@suse.de> 05.07.05 15:42:50 >>>
>On Tue, Jul 05, 2005 at 02:28:27PM +0100, Keir Fraser wrote:
>> 
>> On 5 Jul 2005, at 14:22, Jan Beulich wrote:
>> 
>> >>GRUB has code for switching back into real mode to do bios calls.
We
>> >>could take that, plus video.S, and put them in Xen. Then add an
info
>> >>structure for passing video info up to domain0. It's pretty ugly,
but
>> >>I think there is no nice solution here.
>
>Well, I'd simply leave that job completely to grub as it has to
>deal with that anyway and the multiboot spec have fields to pass
>on that info to the booted kernel.  Xen would simply take that
>and pass it on to the Dom0 kernel, thats it.  And maybe adjust
>it's own row/column counts in case it's vga text mode.

I'm not sure I follow here.

First of all, at least grub 0.9x (which is what I think is currently in
wide-spread use) doesn't seem to have even infrastructure to report
video information, not to think about changing the video mode. But I
agree that that'd be the best place for this to live.

Second, simply passing on the multi-boot info to the guest kernel would
still require that the interface between XEN and the guest kernel be
changed. And if a change is required, then passing the information in a
XEN-determined format seems more portable to me, especially if you
expect EFI to be used as boot loader at some point even on x86, because
then the information would perhaps come in yet another format (and
whatever Linux people might think, I believe that elilo shouldn't become
yet another intermediate layer for booting XEN then).

>> >> Would we also need vesa/vga
>> >>driver code from Linux for setting up font data in some graphics
>> >modes?
>> >
>> >Yes that would clearly be necessary, but perhaps a much more
>> >streamlined mechanism would do for XEN.
>> 
>> If that's the case, I'm sure Gerd can point out the 'moving parts'
that 
>> we actually need to get basic text output working. I was hoping
video.S 
>> alone would be sufficient... :-)
>
>Text mode is really simple, that is just another screen size
>than 80x25, but completely identical otherwise.  Font stuff is
>handled by bios and vga hardware, nothing to worry about here.

That builds on the assumption that the boot loader actually has the
necessary infrastructure. With the assumption that it's quite far away
from that, I would still think that XEN should try provide the ability
to change modes (at least until the boot loader actually does).

>In graphics mode you simply have a linear frame buffer and
>you'll have to do everything yourself.  Linux has compiled-in
>fonts for that.  Quite alot of stuff from drivers/video would
>be needed to get that going in xen, but I wouldn't even try to
>make xen render text in graphics mode and leave that completely
>to the dom0 kernel ...

Once XEN is so stable that you can afford not seeing its initial
messages, leaving the screen alone when in graphics mode is certainly an
option. But I don't think that's an option right now.

Jan

Re: beginnings of allowing more than the basic 80x25 VGAscreen resolution

[Gerd Knorr]

  Hi,

> First of all, at least grub 0.9x (which is what I think is currently in
> wide-spread use) doesn't seem to have even infrastructure to report
> video information, not to think about changing the video mode. But I
> agree that that'd be the best place for this to live.

Distributions have a graphical boot menu, so grub must do some
mode switching already.  Havn't looked at the grub code, but I
think adding that wouldn't be too hard.  Might be vanilla grub
doesn't do that so you'll have to dig into distribution patches.

> Second, simply passing on the multi-boot info to the guest kernel would
> still require that the interface between XEN and the guest kernel be
> changed.

I agree here.

> >Text mode is really simple, that is just another screen size
> >than 80x25, but completely identical otherwise.  Font stuff is
> >handled by bios and vga hardware, nothing to worry about here.
> 
> That builds on the assumption that the boot loader actually has the
> necessary infrastructure. With the assumption that it's quite far away
> from that, I would still think that XEN should try provide the ability
> to change modes (at least until the boot loader actually does).

I would try to hack grub (or syslinux, Tim's multiboot loader is
merged upstream ;) instead of adding a temporary solution to
xen.  YMMV.

> Once XEN is so stable that you can afford not seeing its initial
> messages, leaving the screen alone when in graphics mode is certainly an
> option. But I don't think that's an option right now.

For hacking on xen having a serial console is a great thing.
My xen devel machine doesn't even have a monitor connected ;)

  Gerd

-- 
panic("it works"); /* avoid being flooded with debug messages */

Re: beginnings of allowing more than the basic 80x25 VGAscreen resolution

[David Hopwood]

Keir Fraser wrote:
> On 5 Jul 2005, at 13:58, Gerd Knorr wrote:
> > "Ling, Xiaofeng" <xiaofeng.ling@intel.com> writes:
> 
>>> Is it possible to add some real mode code to xen like video.S in linux
>>> kernel to switch mode?
>>
>> Hmm, how about adding that to the boot loader(s)?
>>
>> IIRC there are some fields in the multiboot info header for that kind
>> of stuff, so grub could setup that and pass on the info to xen (and
>> xen in turn to the dom0 kernel?).

Yes. How this is supposed to work is that the OS's multiboot header
specifies a desired mode:
<http://www.gnu.org/software/grub/manual/multiboot/multiboot.html#Header%20graphics%20fields>
and then the boot loader passes back information about the actual mode
that was set in the vbe_* fields of the information struct.

>> multiboot kernels are started in 32-bit protected mode by the boot
>> loader, i.e. xen has (unlike linux) no 16-bit startup code.  Thus
>> doing 16-bit BIOS calls once xen is running is a bit difficult ...
> 
> GRUB has code for switching back into real mode to do bios calls. We 
> could take that, plus video.S, and put them in Xen. Then add an info 
> structure for passing video info up to domain0. It's pretty ugly, but I 
> think there is no nice solution here. Would we also need vesa/vga driver 
> code from Linux for setting up font data in some graphics modes?

I prefer Gerd's suggestion of relying on the boot loader to set up a
reasonable mode. Multiboot is all about providing a sane initial hardware
state to multiboot-compliant kernels, so that they do not need as much
(preferably not any) of this crufty 16-bit initialization code.
This is code that with a cleaner hardware/BIOS design would not be needed
at all; ideally, OS designers should be able to forget about it like a
bad dream.

On current PC hardware, a boot loader must have code for doing BIOS calls
anyway, so it might as well set up the video mode (and font if needed).
I don't know what modes GRUB currently supports, but if it doesn't support
the > 25-line text modes then that's an RFE for GRUB, not something that
needs to be fixed by adding more cruft to Xen.

-- 
David Hopwood <david.nospam.hopwood@blueyonder.co.uk>

Re: beginnings of allowing more than the basic 80x25 VGAscreen resolution

[Keir Fraser]

On 5 Jul 2005, at 18:22, David Hopwood wrote:

> On current PC hardware, a boot loader must have code for doing BIOS 
> calls
> anyway, so it might as well set up the video mode (and font if needed).
> I don't know what modes GRUB currently supports, but if it doesn't 
> support
> the > 25-line text modes then that's an RFE for GRUB, not something 
> that
> needs to be fixed by adding more cruft to Xen.

I'm pretty sure that GRUB won;t set up all the nice vga gfx modes on 
behalf of an OS, and even if it does you'd still need font data and 
other smarts in the OS to make use of the hi-res mode. Extra patches to 
GRUB are a pain because in my experience they are almost impossible to 
get accepted upstream.

  -- Keir