At Mon, 01 Jan 2024 18:12:03 -0500, Greg Troxel <gdt%lexort.com@localhost> wrote: Subject: Re: annual HOWTO rampage, mini edition > > No need to be perjorative. It should be obvious that all of this was > written in good faith, even if there is a bit of "guess slightly and > wait for corrections, because when you ask for contributions none > arrive". Some of this text is ancient; I started using NetBSD/xen in > 2005 and it predated my use. Sorry, I've just been very annoyed by that old misinformation and how it keeps spreading as further bad and misleading advice on various email threads. SOOO many people have been completely confused and flumoxed by this over the years. > > So, first off, xencons(4) has nothing whatsoever to do with the Xen > > kernel's messages. (yes, "xl dmesg" is how to see them) > > I'm having trouble following this. On my dom0 (NetBSD 10, pretty normal): > > xencons0 at hypervisor0: Xen Virtual Console Driver > vga0 at pci0 dev 2 function 0: Intel 82G45 Integrated Graphics Device (rev. 0x03) > wsdisplay0 at vga0 kbdmux 1: console (80x25, vt100 emulation) > wsmux1: connecting to wsdisplay0 > > which says the dom0 kernel is using wsdisplay0 as the console. That > later makes sense in the vga case. Well if you set "console=pc" in /boot.cfg on the NetBSD-XEN3_DOM0 command line (and everything works OK), then NetBSD will prefer wsdisplay0 as console. For me I consider having to use VGA console on any server-type machine to be a last resort and worst choice over having a serial console, so I guess I'm somewhat biased against "console=pc" for Xen dom0. I do still enable wscons on my Xen servers as I have a display and keyboard attached to them, so this way I can interact directly with them when I'm standing in front of them. There's just no console(4) output on the display of course. This is possible because of course by default the Xen kernel relinquishes the VGA display just before it boots dom0. BTW, the following sentence is not exactly right: Xen when using a vga console does not process console input. At minimum it needs to be prefixed with "By default", as of course it is possible to instruct Xen _not_ to relinquish the VGA device (and I believe by implication this implies the keyboard device as well, though as I understand it this is only useful for various optional debugging features in the Xen kernel). > So is there some hypercall to get the xen messages and that is what > happens with xl dmesg? And a dom0 kernel w/o any kind of console can > still do that? Yean, "xl dmesg" has nothing whatsoever to do with anything in NetBSD. It's all managed between the Xen kernel and the xl(1) API to Xen. > I did some rototilling. Specific 'this is wrong; say that instead" is > welcome. I'd appreciate comments even if confirming from others. We need to note that Xen (at least since 4.13) hides the COM port it is using from the dom0. I.e. by default NetBSD-XEN3_DOM0 can't see any "com0", period. So, when using a serial console (on the first COM port), booting a XEN3_DOM0 kernel with "console=com0" actually attaches the console to xencons(4) (as it's the only active and present console device and the requested device is not found). The "console=com0" parameter, if given, is ignored. I've also confirmed that "console=xencons" is redundant and unnecessary when using a serial console (at least with recent-ish NetBSD, probably 9.x and newer, but maybe going back much further). So in the current version of the HowTo the sample /boot.cfg line should have the "console=com0" part removed, and I would leave out the "console=com1" part for Xen since in Xen the default is "vga,com1", and one can normally also leave out anything about UART settings since that should already have been set properly by /boot (as per the earlier advice of having GENERIC boot with the correct console). menu=Xen:load /netbsd-XEN3_DOM0.gz;multiboot /xen.gz dom0_mem=512M The paragraph of description for this example needs to be rewritten too: If using a serial console the Xen kernel manages the serial port and connects it to the NetBSD-XEN3_DOM0 xencons(4) device. The UART settings can be explicitly reset by the Xen kernel (see xen-command-line(7)), but the settings done by the NetBSD /boot program should persist and will be used by Xen. We should also fix the Xentools package(s) to install xen-command-line(7) and try to upstream that fix. I would also be explicit about the "console=pc" part, along with an example: If using a VGA console for the Xen server, pass "console=pc" to the NetBSD/XEN3_DOM0 command line: menu=Xen:load /netbsd-XEN3_DOM0.gz console=pc;multiboot /xen.gz dom0_mem=512M I think the last paragraph about problems with a default console and differences with GENERIC can simply be removed. Has anyone else experience with Dell iDRAC remote consoles? If so can anyone confirm the problems I've had with Xen-4.15 and Xen-4.18 not being able to display to them and subsequently NetBSD-XEN3_DOM0 also hanging during boot with "console=pc"? If so that should be mentioned. It might be worth mentioning somewhere that NetBSD-XEN3_DOMU kernels always uses xencons(4) as the console device, perhaps in the section describing the interactions with the domU console. Is it worth mentioning that "xl shutdown" of a domU only works if powerd(8) is running, or is that now considered to be a default and assumed part of any NetBSD installation? -- Greg A. Woods <gwoods%acm.org@localhost> Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost> Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgphWYPU68Tq1.pgp
Description: OpenPGP Digital Signature