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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 andexecute>> a BIOS call (marshalling the registers in each direction). We canthen>> get the dom0 kernel to make this hypercall when initialising thevesafb.> 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> 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
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
>>> "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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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._______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> > 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> 1. Doing it from dom0 would require interface changes we don''t have yetAnd 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
<<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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel