There seems to be a some confusion over properly setting up what Xen and dom0 use for console devices. Is anybody actively working on changes in this area? As a simple first step I''m thinking of just adding a hypervisor capability that tells dom0 which device the hypervisor is using for a console. Joe _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 25/1/07 17:00, "Joe Bonasera" <joe.bonasera@sun.com> wrote:> There seems to be a some confusion over properly setting > up what Xen and dom0 use for console devices. > > Is anybody actively working on changes in this area?I''m not sure there''s any confusion. By default Xen uses the VGA console until dom0 starts executing, at which point it gives it up. At that point Xen has no console devices. If the user overrides any settings, for example to give Xen com1 then we make efforts to prevent dom0 from conflicting (e.g., by silently disallowing its attempts to mess with com1). -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser wrote:> On 25/1/07 17:00, "Joe Bonasera" <joe.bonasera@sun.com> wrote: > >> There seems to be a some confusion over properly setting >> up what Xen and dom0 use for console devices. >> >> Is anybody actively working on changes in this area? > > I''m not sure there''s any confusion. By default Xen uses the VGA console > until dom0 starts executing, at which point it gives it up. At that point > Xen has no console devices. If the user overrides any settings, for example > to give Xen com1 then we make efforts to prevent dom0 from conflicting > (e.g., by silently disallowing its attempts to mess with com1). > > -- Keir >The silently disallowing thing, as well as the vga vs. vga all the time is what is causing Solaris users confusion. The standard internal testing setup inside Sun that most people run with is debug Xen and debug dom0 both sharing either the VGA console or a single serial port console. We also see field support of the eventual product needing the ability to interact with both consoles on the same physical device. So we want to make the dom0 just handle sharing the console as automatically as possible. The algorithm I''m envisioning is something like: hyper_cons_dev = ... /* from Xen capabilites, one of com1, com2, vga, or vgakeep */ dom0_cons_dev = ... /* from dom0 command line, one of com1, com2, vga, or hypervisor -- where hypervisor means use the HYPERVISOR_console_io() calls */ then in our dom0 startup we could do something like : if (hyper_cons_dev is vgakeep) if (dom0_cons_dev is vga) set dom0_cons_dev = hypervisor endif else if (hyper_cons_dev is vga) /* should just work */ else if (hyper_cons_dev is same as dom0_cons_dev) set dom0_cons_dev = hypervisor endif If that''s a non-issue for Linux that''s ok, it could just ignore the new capability. Joe _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 25/1/07 18:47, "Joe Bonasera" <joe.bonasera@sun.com> wrote:> The standard internal testing setup inside Sun that most > people run with is debug Xen and debug dom0 both > sharing either the VGA console or a single serial port console. > We also see field support of the eventual product needing the > ability to interact with both consoles on the same physical > device. So we want to make the dom0 just handle sharing the console > as automatically as possible.You can already detect if Xen has locked out com1 or com2: try reading one of the UART registers (or perhaps write-then-read). If you get back all ones then you''re locked out. Maybe a vgakeep flag would be useful. We could add a SIF_VGA_IN_USE flag or something. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Thu, Jan 25, 2007 at 06:55:29PM +0000, Keir Fraser wrote:> On 25/1/07 18:47, "Joe Bonasera" <joe.bonasera@sun.com> wrote: > > > The standard internal testing setup inside Sun that most > > people run with is debug Xen and debug dom0 both > > sharing either the VGA console or a single serial port console. > > We also see field support of the eventual product needing the > > ability to interact with both consoles on the same physical > > device. So we want to make the dom0 just handle sharing the console > > as automatically as possible. > > You can already detect if Xen has locked out com1 or com2: try reading one > of the UART registers (or perhaps write-then-read). If you get back all ones > then you''re locked out. >good to know. so does xen have any uses for serial ports other than as a console device? if not then we can probably use this to detect an in use port and switch the console to use hypervisor interfaces in this case.> Maybe a vgakeep flag would be useful. We could add a SIF_VGA_IN_USE flag or > something. >well, i don''t think the xen vgakeep mode (which is essentially an extension of the default vga mode) really provides us with a usable console configuration since xen doesn''t support any kind of keyboard input. (at least from my reading of the 3.0.3 code i think will only take input from a serial port.) so setting the xen to vga and vgakeep and then setting the dom0 console to the hypervisor would essentially give you a read-only console. also, afaik, the current xen console io interfaces only allow simple reads and writes of mostly uninterpreted character data, so essentially the console is treated as serial device instead of a terminal. so for example, using the current xen console io interfaces there is no way to change a character currently displayed on the screen without knowing the current contents of the screen and re-writing out all those contents. _if_ we want to be able to support access to the xen debugger on a local vga console (and we could always decide that we don''t) then i think that we probably have a few options: - add keyboard support to xen. then xen could handle output on the vga device and input from the keyboard, and the dom0 OS console access would go through hypervisor interfaces. also, modify the xen console interfaces to support some kind of "terminal" access to the console device (ie, write z at location x,y, etc) - add keyboard support to xen. then xen could handle output on the vga device and input from the keyboard. have the host OS to also access the vga and keyboard devices directly. (the tricky part here would be ensuring that xen and dom0 don''t step on each others console output, although xen itself probably shouldn''t be doing too much console output when it hasn''t entered it''s debugger.) - allow xen to call a dom0''s polled io console entry points to obtain input from and do output to the dom0 console device. this would allow xen to use whatever console device the dom0 is configured to use and would require that the dom0 OS register it''s polled io routines with xen. ed ps - fyi, i''m a xen newbie so if i''ve gotten anything wrong or any of this sounds far fetched and/or impossible then i appoligize for my ignorance. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 26/1/07 12:58 am, "Edward Pilatowicz" <edward.pilatowicz@sun.com> wrote:> so does xen have any uses for serial ports other than as a console > device? if not then we can probably use this to detect an in use > port and switch the console to use hypervisor interfaces in this case.You could set up a remote debug session, but that''s not really a normal usage.> well, i don''t think the xen vgakeep mode (which is essentially an > extension of the default vga mode) really provides us with a usable > console configuration since xen doesn''t support any kind of keyboard > input. (at least from my reading of the 3.0.3 code i think will only > take input from a serial port.) so setting the xen to vga and vgakeep > and then setting the dom0 console to the hypervisor would essentially > give you a read-only console.Our observation has been that, as long as Linux keeps the console in text mode (doesn''t switch to X for example) we can let Linux think it owns the VGA console and things don''t screw up if Xen continues to have at it also. Again, this isn''t really something we''d consider as a normal usage scenario -- more something to try if Xen doesn''t boot and you can''t connect a serial line for some reason. Xen doesn''t include a full debugger -- it has a serial gdbstub which does its job quite nicely -- so there''s nothing really to plumb keyboard input into. The set of ''debug keys'' we plan to make accessible via the xm tool. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Fri, Jan 26, 2007 at 09:33:55AM +0000, Keir Fraser wrote:> Xen doesn''t include a full debuggerThere is one out there though... maybe Christopher has thought about this? regards john _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Friday 26 January 2007 11:29, John Levon wrote:> On Fri, Jan 26, 2007 at 09:33:55AM +0000, Keir Fraser wrote: > > Xen doesn''t include a full debugger > > There is one out there though... maybe Christopher has thought about > this?I have a working one. Is there a chance to get the patches into Xen 3.0.6 ? Christoph _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 26/1/07 12:54 pm, "Christoph Egger" <Christoph.Egger@amd.com> wrote:>>> Xen doesn''t include a full debugger >> >> There is one out there though... maybe Christopher has thought about >> this? > > I have a working one. Is there a chance to get the patches into Xen 3.0.6 ?Why would anyone want to debug over a low-res unscrollable VGA console? If you have a serial line connected then you can already debug via gdb, which surely provides a nicer environment? -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> Keir Fraser <Keir.Fraser@cl.cam.ac.uk> 26.01.07 14:11 >>> >On 26/1/07 12:54 pm, "Christoph Egger" <Christoph.Egger@amd.com> wrote: > >>>> Xen doesn''t include a full debugger >>> >>> There is one out there though... maybe Christopher has thought about >>> this? >> >> I have a working one. Is there a chance to get the patches into Xen 3.0.6 ? > >Why would anyone want to debug over a low-res unscrollable VGA console? If >you have a serial line connected then you can already debug via gdb, which >surely provides a nicer environment?This really depends on what you''re used to. I have a really hard time using these scrolling interfaces (I constantly find myself re-typing commands or scrolling back to see the information I just had on the screen, but that scrolled off). This is also why, on the Linux side, I wanted what now is called nlkd (and I was long planning to move this over to Xen, too, but I''m simply not given time to do so). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 26/1/07 1:50 pm, "Jan Beulich" <jbeulich@novell.com> wrote:>> Why would anyone want to debug over a low-res unscrollable VGA console? If >> you have a serial line connected then you can already debug via gdb, which >> surely provides a nicer environment? > > This really depends on what you''re used to. I have a really hard time using > these scrolling interfaces (I constantly find myself re-typing commands or > scrolling back to see the information I just had on the screen, but that > scrolled off). This is also why, on the Linux side, I wanted what now is > called nlkd (and I was long planning to move this over to Xen, too, but I''m > simply not given time to do so).That''s pretty cool. Of course, you could build an old-school all-in-one-screen debugging client talking to a gdbstub backend. Even if incorporating into the kernel image itself, the debugger source code can presumably be maintained separately quite easily (even in a separate repository)? It ought to lend itself to acting as a very separate module quite easily, since it effectively defines a separate execution mode for the CPUs. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser wrote:> On 26/1/07 12:54 pm, "Christoph Egger" <Christoph.Egger@amd.com> wrote: > >>>> Xen doesn''t include a full debugger >>> There is one out there though... maybe Christopher has thought about >>> this? >> I have a working one. Is there a chance to get the patches into Xen 3.0.6 ? > > Why would anyone want to debug over a low-res unscrollable VGA console? If > you have a serial line connected then you can already debug via gdb, which > surely provides a nicer environment? >It''s not so much a choice of wanting to, as having to. Many classes of x86 computers no longer have serial ports. They''re next to impossible to find on new laptops and rapidly getting that way with desktops and workstations. The people defining "platforms" have been killing off "legacy" devices like serial ports in favor of USB. It''s a lot easier to do a little VGA debugging than to convince someone to go out and shop around for some sort of add in card to get a serial port. Joe _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
so it seems that some people are at least interested in accessing the xen debugger on the local vga console keyboard. so what would be any requirements for local console debugger support on xen? - would it be good to have access to vga/keyboard devices while xen is loading? i guess this would depend on if xen currently support dropping to it''s interactive debugger while it is booting up? or only after the host os is booted? - would it be sufficient to only be able to access the xen debugger via a vga/keyboard device after the dom0 os has started up? if so would this be needed very early on in the dom0''s boot or later on after the dom0 has had more time to bring itself up. i''m really haven''t had a huge amount of experience using the xen debugger so i''m not sure what the most common use cases in the past have been. answers to the questions above from people who have used the xen debugger more extensively would be enlightening. ed On Fri, Jan 26, 2007 at 08:01:40AM -0800, Joe Bonasera wrote:> Keir Fraser wrote: > >On 26/1/07 12:54 pm, "Christoph Egger" <Christoph.Egger@amd.com> wrote: > > > >>>>Xen doesn''t include a full debugger > >>>There is one out there though... maybe Christopher has thought about > >>>this? > >>I have a working one. Is there a chance to get the patches into Xen 3.0.6 > >>? > > > >Why would anyone want to debug over a low-res unscrollable VGA console? If > >you have a serial line connected then you can already debug via gdb, which > >surely provides a nicer environment? > > > > It''s not so much a choice of wanting to, as having to. Many classes of x86 > computers no longer have serial ports. They''re next to impossible to find > on new > laptops and rapidly getting that way with desktops and workstations. > The people defining "platforms" have been killing off "legacy" devices like > serial ports in favor of USB. It''s a lot easier to do a little VGA > debugging than > to convince someone to go out and shop around for some sort of add in card > to get a serial port. > > Joe >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel