I'll try to get this ported and committed to the legacy PCI driver before 13.0

I'd like to keep the current distinction - virito_pci and virtio_mmio - so it is clear as to what is being attached. After https://reviews.freebsd.org/D28073 there is much less boilerplate, and not likely another transport is forthcoming.

Committed in dc9029d863dcc48efebb6a31a25553a7459132aa

Folded into https://reviews.freebsd.org/D27915

Folded into https://reviews.freebsd.org/D27919

In D28031#626513, @jrtc27 wrote:

In D28031#626500, @bryanv wrote:

In D28031#626487, @jrtc27 wrote:

<snip>

As a separate thing I would like to update virtio_mmio to return ENXIO when probing instances with no device rather than creating pointless empty device instances as it's not particularly useful (and the AArch64 QEMU virt machine has a particularly large number of MMIO devices available for whatever reason which leads to rather silly device numbers).

I think it is useful that a transport driver has been attached. Also my recollection when I original did it this way for PCI, is that this is needed for if the device (network, block, etc) module is later loaded. In the ensuing decade, devctl has appeared, but for driver development it is nice to just be able to load/unload the module for hack/test/hack.

Oh I didn't mean if a driver wasn't available, I meant if the device ID is 0. If it's non-zero but no driver's available that would still attach ready for if the driver gets loaded later, either automatically by devd or manually by the user.

In D28031#626487, @jrtc27 wrote:

For reference, this is what an AArch64 QEMU virt machine shows in devinfo when using PCI:

root@:/ # devinfo
nexus0
  acpi0
    cpu0
    uart0
    virtio0
    virtio1
    virtio2
    virtio3
    virtio4
    virtio5
    virtio6
    virtio7
    virtio8
    virtio9
    virtio10
    virtio11
    virtio12
    virtio13
    virtio14
    virtio15
    virtio16
    virtio17
    virtio18
    virtio19
    virtio20
    virtio21
    virtio22
    virtio23
    virtio24
    virtio25
    virtio26
    virtio27
    virtio28
    virtio29
    virtio30
    virtio31
    pcib0
      pci0
        hostb0
        virtio32
          vtblk0
        virtio33
          vtnet0
        virtio34
    pci_link0
    pci_link1
    pci_link2
    pci_link3
    acpi_sysresource0
    acpi_button0
    psci0
    gic0
    generic_timer0
  cryptosoft0
  efirtc0
root@:/ # devinfo -p vtblk0
vtblk0 virtio32 pci0 pcib0 acpi0 nexus0
root@:/ # devinfo -p vtblk0 -v
vtblk0 pnpinfo vendor=0x00001af4 device=0x1001 subvendor=0x1af4 device_type=0x00000002
 virtio32 pnpinfo vendor=0x1af4 device=0x1001 subvendor=0x1af4 subdevice=0x0002 class=0x010000 at slot=1 function=0 dbsf=pci0:0:1:0
 pci0
 pcib0 pnpinfo _HID=PNP0A08 _UID=0 _CID=PNP0A03 at handle=\_SB_.PCI0
 acpi0
 nexus0 pnpinfo nexus

As a separate thing I would like to update virtio_mmio to return ENXIO when probing instances with no device rather than creating pointless empty device instances as it's not particularly useful (and the AArch64 QEMU virt machine has a particularly large number of MMIO devices available for whatever reason which leads to rather silly device numbers).

In D28031#626486, @jrtc27 wrote:

In D28031#626481, @bryanv wrote:

This would change the device names in places like devinfo, devctl, vmstat, etc, correct?

Of the transport, yes. The leaf device attached to that doesn't include the transport in it regardless. devinfo will still print the hierarchy so vtpci_driver instances have a pcibX above/next to them. The description of the transport device still includes the transport in it.

This would change the device names in places like devinfo, devctl, vmstat, etc, correct? Frankly, I prefer to keep some indication of the transport used in the device name. I have some WIP man pages changes to add a virtio_pci(4) page for modern-specific tunables, and add missing MLINK's to improve discoverability between device and kernel module names.

Update