vesafb

vesafb

[Nathan King]

[-- Attachment #1.1: Type: text/plain, Size: 719 bytes --]

Hey folks,

I'm trying to get a feel for how all this works as I get ready to really
start monkeying with the driver, so I liberally sprinkled some printk's
around vesafb.c and cfb_fillrect.c and recompiled. However I only ever get
messages from three of the vesafb.c functions, all on bootup, and none from
cfb_fillrect.c. I know doing all those messages will slow down my system(or
they would if they worked right) but I'm just trying to figure out what
files control what.

So my question is, which files are responsible for all these constant
fillrect and bitblt operations, and can they monkeyed with to generate
kernel or other messages?

Using 2.6.16 with fedora core 5 and the VESA driver.

Many thanks,
Nathan

[-- Attachment #1.2: Type: text/html, Size: 754 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



[-- Attachment #3: Type: text/plain, Size: 182 bytes --]

_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

Re: vesafb

[Antonino A. Daplas]

Nathan King wrote:
> Hey folks,
> 
> I'm trying to get a feel for how all this works as I get ready to really
> start monkeying with the driver, so I liberally sprinkled some printk's
> around vesafb.c and cfb_fillrect.c and recompiled. However I only ever
> get messages from three of the vesafb.c functions, all on bootup, and
> none from cfb_fillrect.c. I know doing all those messages will slow down
> my system(or they would if they worked right) but I'm just trying to
> figure out what files control what.
> 
> So my question is, which files are responsible for all these constant
> fillrect and bitblt operations, and can they monkeyed with to generate
> kernel or other messages?

fillrect is called by ops->fill and ops->clear_margins.  The first one
should be called when scrolling the screen, while the second will be
called if xres is not divisible by the fontwidth or yres is not divisible
by the fontheight.

Tony

vesafb

[ron minnich]

Can vesafb be used in a dom0? I ask because I can not get it to work.
I am wondering if vm86mode is verboten in a xen guest.

thanks

ron

RE: vesafb

[Ian Pratt]

> Can vesafb be used in a dom0? I ask because I can not get it to work.
> I am wondering if vm86mode is verboten in a xen guest.

Do you mean the linux kernel vesafb support?

This relies on Linux's very early bzImage real mode code to make the
call to the VESA BIOS to put the framebuffer in graphics mode. Since we
enter PV Linux in 32b mode straight from Xen there's no opportunity to
do this. vm86 mode is not involved.

VESA driver support in the Xserver should work just fine.

As regards enabling vesafb, it might be nice to add support to Xen to
drop into real mode via a trampoline in the bottom megabyte and execute
a BIOS call (marshalling the registers in each direction). We can then
get the dom0 kernel to make this hypercall when initialising the vesafb.


Ron, your BIOS experience would make you the ideal person to do this :-)


[There's code in syslinux that could be cribbed.]

Ian

Re: vesafb

[ron minnich]

On 4/30/07, Ian Pratt <Ian.Pratt@cl.cam.ac.uk> wrote:

> As regards enabling vesafb, it might be nice to add support to Xen to
> drop into real mode via a trampoline in the bottom megabyte and execute
> a BIOS call (marshalling the registers in each direction). We can then
> get the dom0 kernel to make this hypercall when initialising the vesafb.

ok, I have implemented this in linuxbios once already, I will look
into it.I had hoped never to see it again but you can't win them all
:-)

thanks

ron

Re: vesafb

[Jayant Mangalampalli]

[-- Attachment #1.1: Type: text/plain, Size: 767 bytes --]

On 4/30/07, Ian Pratt <Ian.Pratt@xxxxxxxxxxxx> wrote:

>> As regards enabling vesafb, it might be nice to add support to Xen to
>> drop into real mode via a trampoline in the bottom megabyte and
execute
>> a BIOS call (marshalling the registers in each direction). We can
then
>> get the dom0 kernel to make this hypercall when initialising the
vesafb.

> ok, I have implemented this in linuxbios once already, I will look
> into it.I had hoped never to see it again but you can't win them all
-- ron

Can this release be expected some time soon? We are stuck on exactly the
same issue and were thinking on similar lines when we ran into this
discussion. Perhaps the implementation is best left to the experts? :-)

Thanks,
Jayant Mangalampalli


[-- Attachment #1.2: Type: text/html, Size: 3141 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: vesafb

[ron minnich]

It is pretty easy, I sent sample code to Ian, if somebody can show me
how they want it to look in Xen, i.e. where the function gets called
and all that, I guess I can try to put it in -unstable.

ron

RE: vesafb

[Ian Pratt]

> It is pretty easy, I sent sample code to Ian, if somebody can show me
> how they want it to look in Xen, i.e. where the function gets called
> and all that, I guess I can try to put it in -unstable.

I think we want to parse the dom0 kernel's command line looking for a
'vga=' parameter, and if present, setup the appropriate vesa mode just
before un-pausing the newly created dom0.

Best,
Ian 

RE: vesafb

[Kaushik Barde]

Jayant:

Per Ian's comment, you can modify xen/arch/x86/setup.c where the
hypervisor/dom0 commandline gets parsed.. I think..

Something like..

Vga = 791 (16-bit 1024x768)

////
void __init __start_xen(multiboot_info_t *mbi)
{
    char __cmdline[] = "", *cmdline = __cmdline;

   .....

/* Create initial domain 0. */
    dom0 = domain_create(0, 0);
    if ( (dom0 == NULL) || (alloc_vcpu(dom0, 0, 0) == NULL) )
        panic("Error creating domain 0\n");

    dom0->is_privileged = 1;

    /* Post-create hook sets security label. */
    acm_post_domain0_create(dom0->domain_id);

    /* Grab the DOM0 command line. */
    cmdline = (char *)(mod[0].string ? __va(mod[0].string) : NULL);
    if ( cmdline != NULL )
	{
	 parse_vga_commandline(..);
	}
   .....
}

void parse_vga_commandline(..)
{
	init_vga_mode();
}

void Init_vga_mode()
{
	// your code..
	// detect the card, query BIOS and sets up best possible mode
}
////


Thanks.

-Kaushik   
 

-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Ian Pratt
Sent: Monday, May 07, 2007 1:14 PM
To: ron minnich; Jayant Mangalampalli
Cc: xen-devel@lists.xensource.com
Subject: RE: [Xen-devel] vesafb

> It is pretty easy, I sent sample code to Ian, if somebody can show me
> how they want it to look in Xen, i.e. where the function gets called
> and all that, I guess I can try to put it in -unstable.

I think we want to parse the dom0 kernel's command line looking for a
'vga=' parameter, and if present, setup the appropriate vesa mode just
before un-pausing the newly created dom0.

Best,
Ian 

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

RE: vesafb

[Jan Beulich]

>>> "Ian Pratt" <Ian.Pratt@cl.cam.ac.uk> 07.05.07 22:14 >>>
>> It is pretty easy, I sent sample code to Ian, if somebody can show me
>> how they want it to look in Xen, i.e. where the function gets called
>> and all that, I guess I can try to put it in -unstable.
>
>I think we want to parse the dom0 kernel's command line looking for a
>'vga=' parameter, and if present, setup the appropriate vesa mode just
>before un-pausing the newly created dom0.

So you want the same counter intuitive mechanism that native Linux uses
(in that GrUB parses the kernel command line), rather than having the
command line option apply directly to Xen (i.e. vesa=), leaving unhandled
any non-Linux OSes possibly usable as dom0? 

Jan

Re: vesafb

[Keir Fraser]

On 8/5/07 08:22, "Jan Beulich" <jbeulich@novell.com> wrote:

>> I think we want to parse the dom0 kernel's command line looking for a
>> 'vga=' parameter, and if present, setup the appropriate vesa mode just
>> before un-pausing the newly created dom0.
> 
> So you want the same counter intuitive mechanism that native Linux uses
> (in that GrUB parses the kernel command line), rather than having the
> command line option apply directly to Xen (i.e. vesa=), leaving unhandled
> any non-Linux OSes possibly usable as dom0?

Er, what?

GRUB only parses 'vga=' for Linux images. It doesn't do so for multiboot
images. And, even if it did, what does that have to do with non-Linux dom0
OSes?

The reason we plan to use Linux-style 'vga=' is because we can leverage the
fact that people have already learned the hex mode numbers they care about
from using native Linux. Actually I will probably go for 'vga=vesa-<mode>'.

 -- Keir

Re: vesafb

[Jan Beulich]

>>> Keir Fraser <Keir.Fraser@cl.cam.ac.uk> 08.05.07 09:40 >>>
>On 8/5/07 08:22, "Jan Beulich" <jbeulich@novell.com> wrote:
>
>>> I think we want to parse the dom0 kernel's command line looking for a
>>> 'vga=' parameter, and if present, setup the appropriate vesa mode just
>>> before un-pausing the newly created dom0.
>> 
>> So you want the same counter intuitive mechanism that native Linux uses
>> (in that GrUB parses the kernel command line), rather than having the
>> command line option apply directly to Xen (i.e. vesa=), leaving unhandled
>> any non-Linux OSes possibly usable as dom0?
>
>Er, what?
>
>GRUB only parses 'vga=' for Linux images. It doesn't do so for multiboot
>images. And, even if it did, what does that have to do with non-Linux dom0
>OSes?

Exactly, and Ian intends to do the same thing (i.e. parse the Linux-dom0
command line). This is what I consider counter-intuitive - Xen should only
care about its own command line (unless absolutely needed to make
assumptions about dom0's), and GrUB really shouldn't look at Linux'
command line either.

>The reason we plan to use Linux-style 'vga=' is because we can leverage the
>fact that people have already learned the hex mode numbers they care about
>from using native Linux. Actually I will probably go for 'vga=vesa-<mode>'.

Yes, that would have been my second favorite.

Jan

Re: vesafb

[Keir Fraser]

On 8/5/07 08:50, "Jan Beulich" <jbeulich@novell.com> wrote:

>> GRUB only parses 'vga=' for Linux images. It doesn't do so for multiboot
>> images. And, even if it did, what does that have to do with non-Linux dom0
>> OSes?
> 
> Exactly, and Ian intends to do the same thing (i.e. parse the Linux-dom0
> command line). This is what I consider counter-intuitive - Xen should only
> care about its own command line (unless absolutely needed to make
> assumptions about dom0's), and GrUB really shouldn't look at Linux'
> command line either.

Oh, I see, I didn't spot that. Yes, we may as well shift the vga= option
onto Xen's command line. It's what we did with every other option we took
from Linux, so it would also be consistent (apic=, etc.).

I think the reason for grabbing it off dom0's command line is the mindset
that this is merely a 'skanky hack' where we actually only change the mode
immediately before entering dom0 because:
 1. Doing it from dom0 would require interface changes we don't have yet
 2. Doing it earlier in Xen would require us to support text on graphical
lfb, which is a bit of a pain.

So this would be enough of a lashup to support higher-res text console for
dom0, and to support bootsplash (which loads of people want).

 -- Keir

>> The reason we plan to use Linux-style 'vga=' is because we can leverage the
>> fact that people have already learned the hex mode numbers they care about
>> from using native Linux. Actually I will probably go for 'vga=vesa-<mode>'.
> 
> Yes, that would have been my second favorite.

RE: vesafb

[Ian Pratt]

> > Exactly, and Ian intends to do the same thing (i.e. parse the 
> > Linux-dom0 command line). This is what I consider 
> counter-intuitive - 
> > Xen should only care about its own command line (unless absolutely 
> > needed to make assumptions about dom0's), and GrUB really 
> shouldn't look at Linux'
> > command line either.
> 
> Oh, I see, I didn't spot that. Yes, we may as well shift the 
> vga= option onto Xen's command line. It's what we did with 
> every other option we took from Linux, so it would also be 
> consistent (apic=, etc.).

That would make sense if xen could use the graphics framebuffer, but
since xen currently only supports text mode the option really only
applies to dom0. I guess we might add support in future, in which case
parsing it from xen's command line is OK. This may have implications for
other dom0 OSes who are expecting to find the console in text mode,
though.

Ian

Re: vesafb

[Jan Beulich]

> 1. Doing it from dom0 would require interface changes we don't have yet

And in my opinion we never should (based on bad experience in NetWare with
switching back to real mode).

> 2. Doing it earlier in Xen would require us to support text on graphical
>lfb, which is a bit of a pain.

That was actually the intention I had - no acceleration or anything, but simple
text rendering is no big deal (I have code to do this in nlkd). Also we've got
the necessary fonts in memory already.

Jan

Re: vesafb

[Keir Fraser]

On 8/5/07 10:56, "Jan Beulich" <jbeulich@novell.com> wrote:

>> 1. Doing it from dom0 would require interface changes we don't have yet
> 
> And in my opinion we never should (based on bad experience in NetWare with
> switching back to real mode).

That's kind of surprising. As long as the BIOS code and data areas haven't
been clobbered I would expect no problems. Are interrupts and NMIs a hassle?

 -- Keir

RE: vesafb

[Kaushik Barde]

I Agree with Kier. 

And from our experience (Phoenix) BIOS reserved areas usually aren't
clobbered (except for a vendor specific BIOS/system customizations)

I am also not sure about why can't we create Dom0 interface changes?

Like I presented in my email earlier, is following ok?

////
void __init __start_xen(multiboot_info_t *mbi)
{
    char __cmdline[] = "", *cmdline = __cmdline;

   .....

/* Create initial domain 0. */
    dom0 = domain_create(0, 0);
    if ( (dom0 == NULL) || (alloc_vcpu(dom0, 0, 0) == NULL) )
        panic("Error creating domain 0\n");

    dom0->is_privileged = 1;

    /* Post-create hook sets security label. */
    acm_post_domain0_create(dom0->domain_id);

    /* Grab the DOM0 command line. */
    cmdline = (char *)(mod[0].string ? __va(mod[0].string) : NULL);
    if ( cmdline != NULL )
	{
	 parse_vga_commandline(..);
	}
   .....
}

void parse_vga_commandline(..)
{
	init_vga_mode();

}

void Init_vga_mode()
{
	// your code..
	// detect the card, query BIOS and sets up best possible mode
}
////



-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Keir Fraser
Sent: Tuesday, May 08, 2007 3:39 AM
To: Jan Beulich
Cc: ron minnich; Ian Pratt; xen-devel@lists.xensource.com; Jayant
Mangalampalli
Subject: Re: [Xen-devel] vesafb

On 8/5/07 10:56, "Jan Beulich" <jbeulich@novell.com> wrote:

>> 1. Doing it from dom0 would require interface changes we don't have
yet
> 
> And in my opinion we never should (based on bad experience in NetWare
with
> switching back to real mode).

That's kind of surprising. As long as the BIOS code and data areas
haven't
been clobbered I would expect no problems. Are interrupts and NMIs a
hassle?

 -- Keir



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

Re: vesafb

[Keir Fraser]

On 8/5/07 20:20, "Kaushik Barde" <Kaushik_Barde@Phoenix.com> wrote:

> I Agree with Kier.
> 
> And from our experience (Phoenix) BIOS reserved areas usually aren't
> clobbered (except for a vendor specific BIOS/system customizations)
> 
> I am also not sure about why can't we create Dom0 interface changes?
> 
> Like I presented in my email earlier, is following ok?

Jan's specific concerns are relating to interrupts, NMIs and machine-check
exceptions, if we return to real-mode at arbitrary times after the machine
has finished booting. Those concerns are quite reasonable (but, I think,
work-aroundable). However, doing one or two calls back to real mode before
dom0 even starts to execute should definitely not be a problem - that's not
what is being argued against here.

 -- Keir

RE: vesafb

[Kaushik Barde]

<<However, doing one or two calls back to real mode before
 dom0 even starts to execute should definitely not be a problem 
>>

Ok.. We will test this solution.

I am curious,

Why else would you be jumping into real mode after/before the Dom0
creation?

-Kaushik


-----Original Message-----
From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk] 
Sent: Tuesday, May 08, 2007 1:07 PM
To: Kaushik Barde; Jan Beulich
Cc: ron minnich; Ian Pratt; xen-devel@lists.xensource.com; Jayant
Mangalampalli
Subject: Re: [Xen-devel] vesafb

On 8/5/07 20:20, "Kaushik Barde" <Kaushik_Barde@Phoenix.com> wrote:

> I Agree with Kier.
> 
> And from our experience (Phoenix) BIOS reserved areas usually aren't
> clobbered (except for a vendor specific BIOS/system customizations)
> 
> I am also not sure about why can't we create Dom0 interface changes?
> 
> Like I presented in my email earlier, is following ok?

Jan's specific concerns are relating to interrupts, NMIs and
machine-check
exceptions, if we return to real-mode at arbitrary times after the
machine
has finished booting. Those concerns are quite reasonable (but, I think,
work-aroundable). However, doing one or two calls back to real mode
before
dom0 even starts to execute should definitely not be a problem - that's
not
what is being argued against here.

 -- Keir

Re: vesafb

[Keir Fraser]

On 8/5/07 21:47, "Kaushik Barde" <Kaushik_Barde@Phoenix.com> wrote:

> <<However, doing one or two calls back to real mode before
>  dom0 even starts to execute should definitely not be a problem
>>> 
> 
> Ok.. We will test this solution.
> 
> I am curious,
> 
> Why else would you be jumping into real mode after/before the Dom0
> creation?

For one thing, there's some extended BIOS data that Linux would like to get
its hands on. Another is that it might be nice to get the memory-map
information for ourselves instead of relying on the bootloader (there's at
least one system we've seen where GRUB gets it wrong). Really there aren't
that many examples, and they'd all be invoked at start-of-day.

 -- Keir

RE: vesafb

[Kaushik Barde]

Thanks.

Yes, I remember that GRUB bug where the initial memory was incorrectly
reported.

As for the e820 and EBDA, you need them only at machine boot-up.

-Kaushik
 

-----Original Message-----
From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk] 
Sent: Tuesday, May 08, 2007 2:35 PM
To: Kaushik Barde; Jan Beulich
Cc: ron minnich; Ian Pratt; xen-devel@lists.xensource.com; Jayant
Mangalampalli
Subject: Re: [Xen-devel] vesafb

On 8/5/07 21:47, "Kaushik Barde" <Kaushik_Barde@Phoenix.com> wrote:

> <<However, doing one or two calls back to real mode before
>  dom0 even starts to execute should definitely not be a problem
>>> 
> 
> Ok.. We will test this solution.
> 
> I am curious,
> 
> Why else would you be jumping into real mode after/before the Dom0
> creation?

For one thing, there's some extended BIOS data that Linux would like to
get
its hands on. Another is that it might be nice to get the memory-map
information for ourselves instead of relying on the bootloader (there's
at
least one system we've seen where GRUB gets it wrong). Really there
aren't
that many examples, and they'd all be invoked at start-of-day.

 -- Keir

Re: vesafb

[Jan Beulich]

>>> Keir Fraser <Keir.Fraser@cl.cam.ac.uk> 08.05.07 23:34 >>>
>On 8/5/07 21:47, "Kaushik Barde" <Kaushik_Barde@Phoenix.com> wrote:
>
>> <<However, doing one or two calls back to real mode before
>>  dom0 even starts to execute should definitely not be a problem
>>>> 
>> 
>> Ok.. We will test this solution.
>> 
>> I am curious,
>> 
>> Why else would you be jumping into real mode after/before the Dom0
>> creation?
>
>For one thing, there's some extended BIOS data that Linux would like to get
>its hands on. Another is that it might be nice to get the memory-map
>information for ourselves instead of relying on the bootloader (there's at
>least one system we've seen where GRUB gets it wrong). Really there aren't
>that many examples, and they'd all be invoked at start-of-day.

... and for which I had already posted patches to do all that's needed before
entering C code (and namely, before enabling paging and [on x86-64] long
mode), almost like Linux does - I have to admit that I continue to favor that
solution, including extending it to set the VESA mode and, if that's really
important as you say, calling INT 15 fn E820.

Jan

Re: vesafb

[Keir Fraser]

On 9/5/07 08:48, "Jan Beulich" <jbeulich@novell.com> wrote:

>> For one thing, there's some extended BIOS data that Linux would like to get
>> its hands on. Another is that it might be nice to get the memory-map
>> information for ourselves instead of relying on the bootloader (there's at
>> least one system we've seen where GRUB gets it wrong). Really there aren't
>> that many examples, and they'd all be invoked at start-of-day.
> 
> ... and for which I had already posted patches to do all that's needed before
> entering C code (and namely, before enabling paging and [on x86-64] long
> mode), almost like Linux does - I have to admit that I continue to favor that
> solution, including extending it to set the VESA mode and, if that's really
> important as you say, calling INT 15 fn E820.

Yes, I have come around to this. It's not so great that we have to export
that EDD structure out to dom0, but it does look to be mostly laid out
according to BIOS specs. And we can't safely run the code which actually
reads disc sectors after we've messed with IRQ setup anyway (assuming some
BIOSes may depend on interrupts and running with EFLAGS.IF==1, although I'm
not sure about this).

 -- Keir