Hi, I am no expert on console drivers. So I don’t have any technical input. What I hope is to have a FreeBSD work on Gen 2 (UEFI) HyperV as soon as possible. If we back out this patch, we are back to the original state that FreeBSD is not supported on Gen 2 HyperV for amd64, which is very unfortunate.
Back to this patch, still not sure why this hang happens on read hardware, since it shouldn't be using that efiserialio driver if it's not Hyper-V. The only thing that the original owner of the patch could think of is in the probe to rename the driver back to efiserialio if it's not Hyper-V. @Gleb Smirnoff<mailto:gleb...@freebsd.org>, are you able to try following in addition to see if it works? diff --git a/stand/efi/loader/efiserialio.c b/stand/efi/loader/efiserialio.c index 5fbc700f6ac2..24fe7e05c261 100644 --- a/stand/efi/loader/efiserialio.c +++ b/stand/efi/loader/efiserialio.c @@ -265,6 +265,8 @@ comc_probe(struct console *sc) */ env = getenv("smbios.bios.version"); if (env == NULL || strncmp(env, "Hyper-V", 7) != 0) { + /* disable being seen as "comconsole" */ + comconsole.c_name = "efiserialio"; return; } #endif If not I will back it out. Many thanks, Wei From: Warner Losh <i...@bsdimp.com> Sent: Friday, March 31, 2023 6:18 PM To: Toomas Soome <tso...@me.com> Cc: Gleb Smirnoff <gleb...@freebsd.org>; Wei Hu <w...@freebsd.org>; src-committers <src-committ...@freebsd.org>; <dev-commits-src-all@freebsd.org> <dev-commits-src-all@freebsd.org>; <dev-commits-src-m...@freebsd.org> <dev-commits-src-m...@freebsd.org>; i...@freebsd.org; galla...@freebsd.org; kev...@freebsd.org Subject: Re: git: 927358dd98cb - main - amd64 loader: Use efiserialio for Hyper-V booted systems On Fri, Mar 31, 2023 at 12:22 AM Toomas Soome <tso...@me.com<mailto:tso...@me.com>> wrote: On 31. Mar 2023, at 02:40, Warner Losh <i...@bsdimp.com<mailto:i...@bsdimp.com>> wrote: Let's back it out. I didn't get a chance to review it and the duplicated name strikes me as massively unwise. Of course, the efi serial driver never should have had the name comconsole in the first place, imho. It was OK on arm where we couldn't conflict. So let's back it out and talk about how we should do this, including the need to possibly just rename the efi version of the console driver to something else. IMHO, it never should have been comconsole in the first place because it's configured differently than comconsole.... Warner ok, lets start from beginning. The loader device naming is total mess and should not go this way - it is not understandable for users and not understandable for developers. the config below is perfect example of the situation: First the config does set: console="comconsole vidconsole efi” So, we do try to set serial console, bios video console and efi console. So we have “shared” config for BIOS and UEFI loader, which should be totally reasonable from user point of view, but is technically wrong, because BIOS loader has no idea what is efi console and EFI loader has no idea what is vidconsole. So this mixture ends up with message: I strongly disagree this is wrong. You have a boot loader that may have one of many console devices. Not all may be present. console vidconsole is invalid!" And the user will get the similar error when booting BIOS setup. Yes. This message is a bit bogus: it just means we don't have a comconsole configured. And that's fine. It's like if I had ifconfig_ixl0=DHCP and ifconfig_xe0=DHCP in my rc.conf file, imho. It says if they are there, use them. Otherwise don't. We don't have a eth device that's a generic thing. Nor should comconsole be all possible uarts. Then we just set console=“efi”. Then there is setting for uart… This is an orthogonal issue. With todays UEFI setups, the logic is that you set up your hardware, that is, you configure serial port attributes from firmware setup, and the UEFI firmware will populate its internal structures with those values. Agreed. Still orthogonal to the naming issue. Now, first issue is, while developing uefi loader, it was easy path to reuse bits from BIOS loader. smbios, acpi, and sadly, comconsole. Sadly, because comconsole is built assuming x86 IO port features which are not available on other platforms. Agreed. However, we are stuck with comconsole == talk to the hardware and bypass the UEFI firmware. We need to have a efiserial and efivideo device, even for x86, so that we can specify things more closely. Overloading comconsole is unwise. So yes, bios version of comconsole should not have been used to build UEFI loader at all. Yes and no. It's in use today, so saying it shouldn't is about 10 years too late. Now the fun part, even as UEFI does provide SIO API to access serial ports, to read from port, write to port and set attributes, it turns out there are UEFI implementation(s?), where changing some attributes will cause system to hung. Which is the reason, why we need to set up hardware properly from firmware, and our generic config should not try to enforce some other value(s). Default should pick up values from the system. Sure, if the machine operator has some reason to change those values and has tested the change, we should have method to change the config, but again, defaults should come from system setup. Agreed. And it mostly does today. If you have serial redirect, the efi driver does all that automatically. While I see the reasoning to try to create all those different names, maybe the first thing should be to look on this as innocent end user, who has no idea about those fine technical details and historical reasons and is just trying to get system to behave…. It has to be a new name. You can't just overload comconsole and have it work reliably. The user has to understand the technical details. Part of the problem here too is that comconsole's interface says 'use the one at port 0x378' which is impossible without parsing ACPI tables, which the efi loader doesn't do. So there's already a new, kludgy interface to specify the UID of the efiserial device. This UID is just a number with no relationship to the port from machine to machine. So we're already forcing changes on the user. It's no longer transparent: it takes effort to configure and you already have to know the differences because the simple port simply doesn't work. This is why I've been advocating for efi (use CONOUT text interface), efiserial (use the efi's uart routines) and efivideo (use graphic frame buffer) for years. Having this separation will allow people to configure the consoles on their systems more deterministically. For those that have nice serial redirect, 'efi' is the way to go. It just does the right thing. For those that do not, then you can use one or more of efiserial and efivideo to get the combination you want. Plus we can move the graphics dependencies into efivideo and get rid of the crazy stubs that things like kboot need that can never ever have graphical video. I'm still mad that my desire for this was ignored when the graphics stuff was added When we bring this driver back, it absolutely must have a new name. It cannot try to 'fake' it by doing the games it's doing. That simply won't work and breaks many working configurations today. So my suggestion is that we have a new efiserial driver, hyperV uses it. We rename the current efi serial interface to be efiserial. On aarch64 (and on aarch64 only) we have a new comconsole driver that just redirects to efiserial. It doesn't try to change the name of anything, nor try to do anything else. Plus it should start warning when you are trying to use the x86-only configuration knobs of comconsole. And starting after the 14 branch, it should start warning people should use efiserial insteaed. And we never, ever ever again try to do aliases that aren't really the same device and have different configuration needs under the covers. Warner just my 2 cents, toomas On Thu, Mar 30, 2023 at 5:31 PM Gleb Smirnoff <gleb...@freebsd.org<mailto:gleb...@freebsd.org>> wrote: Wei, Kyle, this commit hangs loader on real hardware, at least on some of it. The loader prints list of consoles and hangs hard: [Thu Mar 30 20:46:12 2023]^M|^HLoading /boot/loader.conf^M ^M/^Hconsole vidconsole is invalid!^M ^MAvailable consoles:^M ^M efi^M ^M comconsole^M ^M comconsole^M ^M nullconsole^M ^M spinconsole^M Machine is unrecoverable unless you got alternate boot media and access to BMC console. First, please DO NOT MFC this as scheduled. Second, let's try to fix it or back it out if we hear from any other CURRENT user. Our configuration isn't special. This is what we got in loader.conf, related to consoles: console="comconsole vidconsole efi" comconsole_speed=115200 comconsole_port=0x3e8 console="efi" hw.uart.console="io:1016,br:115200" On Sat, Mar 18, 2023 at 07:20:33AM +0000, Wei Hu wrote: W> The branch main has been updated by whu: W> W> URL: https://cgit.FreeBSD.org/src/commit/?id=927358dd98cb902160093e0dc0bac002d6b43858<https://cgit.freebsd.org/src/commit/?id=927358dd98cb902160093e0dc0bac002d6b43858> W> W> commit 927358dd98cb902160093e0dc0bac002d6b43858 W> Author: Wei Hu <w...@freebsd.org<mailto:w...@freebsd.org>> W> AuthorDate: 2023-03-14 15:13:46 +0000 W> Commit: Wei Hu <w...@freebsd.org<mailto:w...@freebsd.org>> W> CommitDate: 2023-03-18 07:07:35 +0000 W> W> amd64 loader: Use efiserialio for Hyper-V booted systems W> W> UEFI provides ConIn/ConOut handles for consoles that it supports, W> which include the text-video and serial ports. When the serial port W> is available, use the UEFI driver instead of direct io-port accesses W> to avoid conflicts between the firmware and direct hardware access, as W> happens on Hyper-V (Azure) setups. W> W> This change enables efiserialio to be built for efi-amd64 and has W> higher order priority vs comconsole, and only uses efiserialio W> if the hypervisor is Hyper-V. When efiserialio successfully W> probes, it will set efi_comconsole_avail=true which will prevent W> comconsole from probing in this setup. W> W> Tested on Hyper-V, ESXi and Azure VMs. W> W> PR: 264267 W> Reviewed by: kevans, whu W> Tested by: whu W> Obtained from: Rubicon Communications, LLC (Netgate) W> MFC after: 2 weeks W> Sponsored by: Rubicon Communications, LLC (Netgate) W> --- W> stand/efi/loader/arch/amd64/Makefile.inc | 1 + W> stand/efi/loader/bootinfo.c | 11 ++++++-- W> stand/efi/loader/conf.c | 6 +++++ W> stand/efi/loader/efiserialio.c | 43 ++++++++++++++++++++++++++++---- W> stand/i386/libi386/comconsole.c | 14 +++++++++++ W> 5 files changed, 68 insertions(+), 7 deletions(-) W> W> diff --git a/stand/efi/loader/arch/amd64/Makefile.inc b/stand/efi/loader/arch/amd64/Makefile.inc W> index 0d9e2648cb59..bd89044bd6c7 100644 W> --- a/stand/efi/loader/arch/amd64/Makefile.inc W> +++ b/stand/efi/loader/arch/amd64/Makefile.inc W> @@ -5,6 +5,7 @@ SRCS+= amd64_tramp.S \ W> elf64_freebsd.c \ W> trap.c \ W> multiboot2.c \ W> + efiserialio.c \ W> exc.S W> W> .PATH: ${BOOTSRC}/i386/libi386 W> diff --git a/stand/efi/loader/bootinfo.c b/stand/efi/loader/bootinfo.c W> index 939f2cf4c3fe..d79f59343af1 100644 W> --- a/stand/efi/loader/bootinfo.c W> +++ b/stand/efi/loader/bootinfo.c W> @@ -119,10 +119,17 @@ bi_getboothowto(char *kargs) W> if (tmp != NULL) W> speed = strtol(tmp, NULL, 0); W> tmp = getenv("efi_com_port"); W> - if (tmp == NULL) W> - tmp = getenv("comconsole_port"); W> if (tmp != NULL) W> port = strtol(tmp, NULL, 0); W> + if (port <= 0) { W> + tmp = getenv("comconsole_port"); W> + if (tmp != NULL) W> + port = strtol(tmp, NULL, 0); W> + else { W> + if (port == 0) W> + port = 0x3f8; W> + } W> + } W> if (speed != -1 && port != -1) { W> snprintf(buf, sizeof(buf), "io:%d,br:%d", port, W> speed); W> diff --git a/stand/efi/loader/conf.c b/stand/efi/loader/conf.c W> index 863c9188c72c..051e1a3381d1 100644 W> --- a/stand/efi/loader/conf.c W> +++ b/stand/efi/loader/conf.c W> @@ -81,6 +81,9 @@ struct netif_driver *netif_drivers[] = { W> W> extern struct console efi_console; W> extern struct console comconsole; W> +#if defined(__amd64__) W> +extern struct console eficomconsole; W> +#endif W> #if defined(__amd64__) || defined(__i386__) W> extern struct console nullconsole; W> extern struct console spinconsole; W> @@ -88,6 +91,9 @@ extern struct console spinconsole; W> W> struct console *consoles[] = { W> &efi_console, W> +#if defined(__amd64__) W> + &eficomconsole, W> +#endif W> &comconsole, W> #if defined(__amd64__) || defined(__i386__) W> &nullconsole, W> diff --git a/stand/efi/loader/efiserialio.c b/stand/efi/loader/efiserialio.c W> index 375e679d2590..5fbc700f6ac2 100644 W> --- a/stand/efi/loader/efiserialio.c W> +++ b/stand/efi/loader/efiserialio.c W> @@ -69,6 +69,11 @@ static int comc_speed_set(struct env_var *, int, const void *); W> W> static struct serial *comc_port; W> extern struct console efi_console; W> +bool efi_comconsole_avail = false; W> + W> +#if defined(__amd64__) W> +#define comconsole eficomconsole W> +#endif W> W> struct console comconsole = { W> .c_name = "comconsole", W> @@ -254,11 +259,22 @@ comc_probe(struct console *sc) W> char *env, *buf, *ep; W> size_t sz; W> W> +#if defined(__amd64__) W> + /* W> + * For x86-64, don't use this driver if not running in Hyper-V. W> + */ W> + env = getenv("smbios.bios.version"); W> + if (env == NULL || strncmp(env, "Hyper-V", 7) != 0) { W> + return; W> + } W> +#endif W> + W> if (comc_port == NULL) { W> comc_port = calloc(1, sizeof (struct serial)); W> if (comc_port == NULL) W> return; W> } W> + W> /* Use defaults from firmware */ W> comc_port->databits = 8; W> comc_port->parity = DefaultParity; W> @@ -308,6 +324,10 @@ comc_probe(struct console *sc) W> comc_port_set, env_nounset); W> W> env = getenv("efi_com_speed"); W> + if (env == NULL) W> + /* fallback to comconsole setting */ W> + env = getenv("comconsole_speed"); W> + W> if (comc_parse_intval(env, &val) == CMD_OK) W> comc_port->baudrate = val; W> W> @@ -318,8 +338,13 @@ comc_probe(struct console *sc) W> comc_speed_set, env_nounset); W> W> comconsole.c_flags = 0; W> - if (comc_setup()) W> + if (comc_setup()) { W> sc->c_flags = C_PRESENTIN | C_PRESENTOUT; W> + efi_comconsole_avail = true; W> + } else { W> + /* disable being seen as "comconsole" */ W> + comconsole.c_name = "efiserialio"; W> + } W> } W> W> static int W> @@ -489,6 +514,7 @@ comc_setup(void) W> { W> EFI_STATUS status; W> UINT32 control; W> + char *ev; W> W> /* port is not usable */ W> if (comc_port->sio == NULL) W> @@ -498,10 +524,17 @@ comc_setup(void) W> if (EFI_ERROR(status)) W> return (false); W> W> - status = comc_port->sio->SetAttributes(comc_port->sio, W> - comc_port->baudrate, comc_port->receivefifodepth, W> - comc_port->timeout, comc_port->parity, W> - comc_port->databits, comc_port->stopbits); W> + ev = getenv("smbios.bios.version"); W> + if (ev != NULL && strncmp(ev, "Hyper-V", 7) == 0) { W> + status = comc_port->sio->SetAttributes(comc_port->sio, W> + 0, 0, 0, DefaultParity, 0, DefaultStopBits); W> + } else { W> + status = comc_port->sio->SetAttributes(comc_port->sio, W> + comc_port->baudrate, comc_port->receivefifodepth, W> + comc_port->timeout, comc_port->parity, W> + comc_port->databits, comc_port->stopbits); W> + } W> + W> if (EFI_ERROR(status)) W> return (false); W> W> diff --git a/stand/i386/libi386/comconsole.c b/stand/i386/libi386/comconsole.c W> index ed1f1aa08ed7..3fbb6a292c19 100644 W> --- a/stand/i386/libi386/comconsole.c W> +++ b/stand/i386/libi386/comconsole.c W> @@ -85,6 +85,20 @@ comc_probe(struct console *cp) W> int speed, port; W> uint32_t locator; W> W> +#if defined(__amd64__) W> + extern bool efi_comconsole_avail; W> + W> + if (efi_comconsole_avail) { W> + /* W> + * If EFI provides serial I/O, then don't use this legacy W> + * com driver to avoid conflicts with the firmware's driver. W> + * Change c_name so that it cannot be found in the lookup. W> + */ W> + comconsole.c_name = "xcomconsole"; W> + return; W> + } W> +#endif W> + W> if (comc_curspeed == 0) { W> comc_curspeed = COMSPEED; W> /* -- Gleb Smirnoff
