[email protected] writes: > On Sat, 3 Jan 2026, Paul B. Henson wrote: > >> On Sat, Jan 03, 2026 at 08:11:02PM -0800, Mike Larkin wrote: >> >> > Should we remove this if it's dead code? Or finish it? Or enable it if it >> > was >> > finished but someone forgot to enable it? >> >> I enabled debugging and it looks like it doesn't support the multiport >> extension: >> >> viocon0 at virtio5 -MultiPort -EmergWrite +RingIndirectDesc >> -RingEventIdx +Version1 >> >> I haven't been able to get it to work, not sure if that's why. >> Originally qemu had a "virtio-console" device that only supported a >> single port, then it was enhanced to be called "virtio-serial" and >> supported multiple ports per device: >> >> https://fedoraproject.org/wiki/Features/VirtioSerial >> >> I feel like there's a mismatch between the driver and the newer virtual >> serial port hardware, but this level of driver operation isn't my usual >> forte so I can't say for sure. >> >> From my perspective, it would be great if somebody updated it :), but >> enabling it as it is doesn't seem a good idea as it doesn't appear to >> work 8-/. >> >> It looks like the FreeBSD virtio_console driver supports the current >> multiport virtio-serial device and works with qemu and the qemu guest >> agent. The code is somewhat similar but also drastically different ;). >> >> Thanks for the reply... >> > > It has a number of limitations that makes it only usable for very specific > use cases. > > 1) It does not support to be used as kernel boot console. > > There are two main problems to make this work: > > Firstly, the way openbsd console works, device detection would have to > happen in the boot loader (or in the hypervisor for direct kernel boot). > For the legacy boot loader, this would require implementing a whole lot of > PCI infrastructure first. For the EFI boot loader, it is likely a lot > easier as EFI has APIs for enumerating PCI devices. For direct kernel > boot, it is even easier and I have PoC code to make this work with some > hypervisor we use internally. I somewhat want to look at making it work > with efiboot, but that is nowhere near the top of my todo list. Not sure > if there is interest to make it work with vmd.
Doesn't EFI provide input/output functions that could abstract this if the firmware is initializing and managing the virtio console device? This should at least let the EFI boot loader work if we're using those hooks on amd64...but I haven't looked. To your point I don't think you'd get a proper console initialized for the kernel to use once the EFI loader boots the kernel and exits the context of the EFI Boot Services. > > Secondly, in order to make input work during early boot (for UKC and DDB), > one needs memory for the virt queues before malloc works. This can be done > but is some work. > > Also, one needs some hacks to make PCI config space access and PCI BAR > mapping work before pci devices have been probed. > > > 2) It does not support the multiport feature. > > This would also be some work. > > OpenBSD does not support dynamic device nodes, so this would need some > infrastructure for matching port names to device nodes. This would > probably use some ioctl unless someone has a better idea. I don't like > parsing dmesg for such info. > > Also, the design of the events used by the multiport feature is ugly in > that the device will send an ADD event for a port, and then it may or may > not send a CONSOLE_PORT event which says that this device is a console. It > never sends an event that says "configuration for this port is complete > and it is not a console". My understanding was that only the ports that > got a CONSOLE_PORT event should have a TTY (Linux does it this way IIRC). > But having both TTY and non-TTY ports complicates things. I think one > would like to have a fixed set of device nodes for TTY-ports and a > distinct set of device nodes for non-TTY-ports. But freebsd seems to > allocate a tty for every port, so maybe all this is not necessary after > all. > > > A problem with the missing multiport feature is that libvirt has a rather > fixed notion of how the ports are to be used. At least this was the case > the last time I tried it. I am sure that it is possible to make viocon(4) > in its current state work with qemu when starting qemu directly. But > without the multiport feature is is very difficult or impossible to > configure qemu in the right way when using libvirt. > > > Given these limitations, I think having viocon disabled by default is the > correct choice. However, as I have some use for it, I would prefer not to > remove it. Also, I did the PoC for use as kernel boot console only > recently and I would like to wait and see if I can make some more progress > there. > > Cheers, > Stefan
