viocon(4): New virtio tty driver imported from OpenBSD.

viocon* at virtio?

/dev/ttyVI??

Tested under qemu with:

qemu-system-aarch64 ... \
-device virtio-serial \
-chardev socket,path=/tmp/ttyVI00,server=on,wait=off,id=ttyVI00 \
-device virtconsole,chardev=ttyVI00,name=org.NetBSD.dev.ttyVI00 \
...

I updated MAKEDEV.conf to create /dev/ttyVI?? on all ports where it
looks likely to work based on:
(a) having pci or a non-pci virtio attachment,
(b) `qemu-system-$ARCH -M ?' mentioned something resembling the port,
and
(c) `qemu-system-$ARCH -device virtio-serial' launched without
complaining about the virtio-serial device.

(Criterion (c) excluded sparc and sparc64.)

revert previous, unintended, commit

<sys/pmc.h> is gone; dont

branches: 1.2.2; 1.2.4;
Add Virtio MMIO transport.

Adapted in part from OpenBSD.

shuffle mechanics of files.virtio config(5) include location,
without actually moving the contents thereof from dev/pci yet

viocon(4): Defer viocon_rx_fill til after virtio_child_attach_finish.

Since virtio.c 1.66, virtqueue_enqueue* can't be used until after
virtio_child_attach_finish completes.

https://mail-index.netbsd.org/source-changes/2023/03/23/msg143799.html

PR kern/58555: Kernel panic during boot when using viocon with PCIe

branches: 1.9.6;
viocon(4): Show error in assertion failure.

Added functions to set interrupt handler and index into virtqueue

viocon(4): fix not to allocate unused virtqueue

viocon(4) allocates 4 virtqueues but it only uses 2 (0 and 1) queues.

Set virtqueues in virtio_child_attach_finish

The number of virtqueue maybe change in a part of VirtIO devices
(e.g. vioif(4)). And it is fixed after negotiation of features.
So the configuration is moved into the function.

branches: 1.5.4;
viocon(4): Omit unused sc_dmamap.

viocon(4): Fix bus_dmamap_sync after tx: POSTWRITE, not POSTREAD.

viocon(4): Fix $NetBSD$ rcsid.

viocon(4): Fix tty device number.

viocon(4): New virtio tty driver imported from OpenBSD.

viocon* at virtio?

/dev/ttyVI??

Tested under qemu with:

qemu-system-aarch64 ... \
-device virtio-serial \
-chardev socket,path=/tmp/ttyVI00,server=on,wait=off,id=ttyVI00 \
-device virtconsole,chardev=ttyVI00,name=org.NetBSD.dev.ttyVI00 \
...

I updated MAKEDEV.conf to create /dev/ttyVI?? on all ports where it
looks likely to work based on:
(a) having pci or a non-pci virtio attachment,
(b) `qemu-system-$ARCH -M ?' mentioned something resembling the port,
and
(c) `qemu-system-$ARCH -device virtio-serial' launched without
complaining about the virtio-serial device.

(Criterion (c) excluded sparc and sparc64.)

branches: 1.2.4;
PR 58681: add a port of the OpenBSD viogpu(4) driver written by
Joshua Stein <jcs@openbsd.org>.
Port by George Matsumura with help from Jiaxun Yang.

virtio(4): Consolidate kernel configs.

No functional change intended.

Leave `# XXX ?' comments where I don't know why the driver in
question is excluded. (Typical reason is that PAGE_SIZE is not 4096
but I didn't investigate -- if you do investigate, please either
update the comment if you determine a reason, or enable the driver if
you don't.)

PR kern/59211: vio9p(4): missing from various GENERICs and MAKEDEVs

PR 58681: add a port of the OpenBSD viogpu(4) driver written by
Joshua Stein <jcs@openbsd.org>.
Port by George Matsumura with help from Jiaxun Yang.

branches: 1.14.2;
Fix a null dereference (on attach failure).
During cleanup, setup_queue may be called even before vsc->sc_vqs is assigned.

Perform VirtIO 1.0 feature negotation in the MMIO transport. This is
required for HV's that have MMIO-v2 and don't support transitional devices.

- The VirtIO 1.0 spec says that the MMIO interface uses little-endian
registers. For some VMs, at least, this appears to be independent of
the config/struct byte-order. Detect this and handle it.
- Add support for the "v2" MMIO personality.

virtio(4): Fix byte order of DMA data for armeb in the same manner as
aarch64eb.

Fix comments to explain what is going on for {arm,aarch64}eb on QEMU.
This is not due to QEMU bugs; it correctly configures everything for
little-endian environment, and we forcibly change byte order only for
CPU cores during kernel bootstrap.

Use enumeration for state of a child driver instead of flags
and check its detaching by using sc->sc_child in virtio_softc

pointed out by riastradh, thanks.
fixes PR/57357

Fix wrong variable names

This fixes build errors in virtio_mmio.c

Added flags to store status of attaching a virtio device

This prevents a panic on reboot after a virtio device had called
virtio_child_attach_failed().

branches: 1.7.4;
rename "setup_interrupts" to "alloc_interrupts"
in virtio_mmio and virtio_acpi

This should fix build failure on evbarm.

Add virtio mmio probe function

Rewrite and streamline virtio device config read/write and explicitly cater
for the Aarch64-eb bus problem with Qemu. This removes lots of bus_space
`magic' and cleans up the code.

Add VirtIO PCI v1.0 attachments and fix the drivers affected.

The vioif, ld, scsi, viornd and viomb devices were adjusted when needed and
tested both in legacy 0.9 and v1.0 attachments trough PCI on amd64, sparc64,
aarch64 and aarch64-eb. ACPI/FDT attachments also tested on
aarch64/aarch64-eb.

Known issues

* viomb on aarch64 works only with ACPI/FDT attachment but not with PCI
attachment. PCI and ACPI/FDT attachment works on aarch64-eb.

* virtio on sparc64 attaches but is it not functioning though not a
regression.

branches: 1.3.2;
MMIO configuration space is in guest byte order. AArch64 BE is special,
as the guest starts in LE and we switch to BE after the kernel starts.
For this case, we need to byte swap all config space accesses.

branches: 1.2.2;
Add cfprint_t virtiobusprint() and use it for virtio_mmio.

Add Virtio MMIO transport.

Adapted in part from OpenBSD.

Perform VirtIO 1.0 feature negotation in the MMIO transport. This is
required for HV's that have MMIO-v2 and don't support transitional devices.

- The VirtIO 1.0 spec says that the MMIO interface uses little-endian
registers. For some VMs, at least, this appears to be independent of
the config/struct byte-order. Detect this and handle it.
- Add support for the "v2" MMIO personality.

rename "setup_interrupts" to "alloc_interrupts"
in virtio_mmio and virtio_acpi

This should fix build failure on evbarm.

Add virtio mmio probe function

branches: 1.3.14;

Do the previous in the way it probably should have been in the first place.

Be consistent with double include guard name (clang actually detects this)

branches: 1.1.2; 1.1.4;
Add Virtio MMIO transport.

Adapted in part from OpenBSD.

Add support for command line MMIO devices, at least qemu and
Firecracker pass MMIO virtual devices mapping through the kernel
command line.
This driver is based on Colin Percival's FreeBSD virtio_mmio_cmdline.c
https://github.com/freebsd/freebsd-src/blob/main/sys/dev/virtio/mmio/virtio_mmio_cmdline.c

The following kernel options are needed

options MPBIOS
options MPTABLE_LINUX_BUG_COMPAT

As are these drivers

pv* at pvbus?
virtio* at pv?

Exemple qemu usage on a Linux host to boot a NetBSD guest:

qemu-system-x86_64 \
-M microvm,x-option-roms=off,rtc=on,acpi=off,pic=off,accel=kvm \
-m 256 -cpu host -kernel ${KERNEL} \
-append "root=ld0a console=com rw -v" \
-device virtio-blk-device,drive=hd0 \
-drive file=${IMG},format=raw,id=hd0 \
-device virtio-net-device,netdev=net0 \
-netdev user,id=net0,ipv6=off,hostfwd=::2200-:22 \
-global virtio-mmio.force-legacy=false -display none -serial stdio

A lightweight kernel configuration named MICROVM if available for this
use case.