Xen devel - Jul 2005 - beginnings of allowing more than the basic 80x25 VGA screen resolution

With stack traces (during kernel crashes) being usually quite long, extending
the capacity of the screen to at least 80x30 (20%) may already be considered
helpful. I''m certain the patches won''t be accepted as-is
(namely the change to the start_info structure), but I need to get an
understanding at what the expectations are to then try to adjust them.

Jan




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 7/1/05, Jan Beulich <JBeulich@novell.com>
wrote:
> With stack traces (during kernel crashes) being usually quite long,
extending the capacity of the screen to at least 80x30 (20%) may already be
considered helpful. I''m certain the patches won''t be accepted
as-is (namely the change to the start_info structure), but I need to get an
understanding at what the expectations are to then try to adjust them.
You can move the kernel console over to a serial port with
console=ttyS0,11500 on the kernel boot line.  Would it be easier for
Xen to use virtual serial ports to capture the console?

-- 
Jon Smirl
jonsmirl@gmail.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 1 Jul 2005, at 16:48, Jan Beulich wrote:
> With stack traces (during kernel crashes) being usually quite long, 
> extending the capacity of the screen to at least 80x30 (20%) may 
> already be considered helpful. I''m certain the patches
won''t be
> accepted as-is (namely the change to the start_info structure), but I 
> need to get an understanding at what the expectations are to then try 
> to adjust them.
I''ll happily take a patch that increases range of text modes supported 
by Xen. But why bother to propagate this info to XenLinux? You can set 
a vga-mode parameter on XenLinux''s command line. To make this easier, 
we could have Xen automatically add a suitable mode parameter to 
XenLinux command line, based on what was passed to Xen, if one wasn;t 
specified by the administrator.

The only downside of this is that, without hacks, XenLinux will 
probably reset the screen when it starts up (so you lose tail end of 
Xen output). I wonder if that is really much of a problem -- if 
XenLinux has booted far enough to actually reset vga, and then crashes, 
it''s unlikely the tail end of Xen bootstrap output is actually very 
interesting. Certainly not interesting enough to implement and maintain 
big hacks to vga code.

  -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

>I''ll happily take a patch that increases range of text modes
supported
>by Xen. But why bother to propagate this info to XenLinux? You can set
>a vga-mode parameter on XenLinux''s command line. To make this
easier,
>we could have Xen automatically add a suitable mode parameter to 
>XenLinux command line, based on what was passed to Xen, if one wasn;t
>specified by the administrator.
Hmm, interesting. I would have hoped such thing would exist, but I
can''t see how it could work, since the code affected by
CONFIG_VIDEO_SELECT (which is what in non-guest Linux deals with the
vga= option) doesn''t even exist in XenLinux. Further more, since XEN is
a multiboot image, it would require infrastructure to switch back to
real mode for issuing the necessary INT10-s in the guest kernel, which I
think is neither very desirable nor existing.

So I must be missing something, but I''d need a pointer at where I would
have to look for the alternative code.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 4 Jul 2005, at 08:28, Jan Beulich wrote:
> Hmm, interesting. I would have hoped such thing would exist, but I
> can''t see how it could work, since the code affected by
> CONFIG_VIDEO_SELECT (which is what in non-guest Linux deals with the
> vga= option) doesn''t even exist in XenLinux. Further more, since
XEN is
> a multiboot image, it would require infrastructure to switch back to
> real mode for issuing the necessary INT10-s in the guest kernel, which 
> I
> think is neither very desirable nor existing.
>
> So I must be missing something, but I''d need a pointer at where I
would
> have to look for the alternative code.
We could certainly add a way to propagate the mode option through to 
the vga driver, but is the Linux vga driver really unable to switch 
modes without bios help? Is there support for a protected-mode vesa/vbe 
driver instead?

  -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

>We could certainly add a way to propagate the mode option through to 
>the vga driver, but is the Linux vga driver really unable to switch 
>modes without bios help? Is there support for a protected-mode
vesa/vbe 
>driver instead?
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.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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

>> 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.
At least for VBE 2.0 such code can''t exist; the protected mode
interface only covers
- setting the memory window
- setting the display start
- setting the primary palette
and I don''t think 3.0 significantly extended that interface. The
assumption here is that any program wishing to use this is going to set
up its video mode once and for all in real mode, and then only require
some limited support in setting certain output-related things.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Keir Fraser <Keir.Fraser@cl.cam.ac.uk> writes:
> > 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
Exactly.  A simple way to get more screen lines is to load a 8x8
screen font though.
> 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.
vbe 2.0 yes, not sure about 3.0.

For mode switching from protected mode you need 3.0 though, 2.0
protected mode support is _very_ limited (you can do panning and
palette register programming, but no mode switching).  And I think
even for vbe 3.0 you need some real mode code to figure the protected
mode entry point, so paravirtual linux wouldn''t be able to do that
without help from xen.

  Gerd

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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Gerd Knorr <kraxel <at> suse.de> writes:
> 
> Keir Fraser <Keir.Fraser <at> cl.cam.ac.uk> writes:
> 
> > > 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
> 
> Exactly.  A simple way to get more screen lines is to load a 8x8
> screen font though.
> 
> > 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.
> 
> vbe 2.0 yes, not sure about 3.0.
> 
> For mode switching from protected mode you need 3.0 though, 2.0
> protected mode support is _very_ limited (you can do panning and
> palette register programming, but no mode switching).  And I think
> even for vbe 3.0 you need some real mode code to figure the protected
> mode entry point, so paravirtual linux wouldn''t be able to do that
> without help from xen.
The VBE3.0 spec shows clearly how to figure out the protected mode entry point:
copy the video bios to another location and search for the PMInfoBlock
structure, identified by a four-byte signature "PMID". In the
structure you find
the protected mode entry point.
At the moment I am working on initializing graphics mode via the protected mode
VBE interface. So far I found the PMInfoBlock, now I try to figure out how to
set up the needed 16bit-registers to do the lcall into the video bios (at the
protected mode entry point). Any code snippets e.g. for switching to a 16bit
stack selector prior to the lcall are wellcome...

Matthias Huber



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Matthias Huber <hubermat@gmx.de> writes:
> protected mode entry point). Any code snippets e.g. for switching to a
16bit
> stack selector prior to the lcall are wellcome...
linux apm code should have something, apm bios is 16 bit as well.

HTH,

  Gerd

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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel