I would like to write it in a slightly different way:

	const int res_types[] = { SYS_RES_IOPORT, SYS_RES_MEMORY };
...
	int i;
...
	/*
	 * Most hypervisors export the common configuration structure in IO
	 * space, but some use memory space; try both.
	 */
	for (i = 0; nitems(res_type); i++) {
		rid = PCIR_BAR(0);
		sc->vtpci_res_type = res_types[i];
		sc->vtpci_res = bus_alloc_resource_any(dev, res_types[i], &rid,
		    RF_ACTIVE);
		if (sc->vtpci_res == NULL) {
			device_printf(dev, "cannot map I/O nor memory space\n");
			return (ENXIO);
		}
	}

Well, the final NULL-check has to be outside the loop, or else it will always do it wrong:

1. If it's using IOPORT, then the first time through the loop, bus_alloc_resource_any() will return non-NULL, so it will not print or return. It will go on to re-run the loop with MEMORY, bus_alloc_resource_any() *will* return NULL, and it will then do the print and return.
2. If it's using MEMORY, then the first time through the loop, bus_alloc_resource_any() will return NULL, and it will then do the print and return.

Either way, sc->vtpci_res is NULL, the error is printed, and ENXIO is returned. So, you still need to do the break-if-non-NULL inside the loop, and move the NULL-check, print, and return outside the loop.

The change was proposed to deal with a modified version of qemu found in VPS vendors. Under the hood, a legacy virtio was presented, but with bar0's type being memory space instead of I/O space. The intention behind was for performance reason from the vendors' point of view.

Below is a line quoted from Virtio 1.1 spec, which people may find non-standard compliant:

Legacy drivers skipped the Device Layout Detection step, assuming legacy device configuration space in BAR0 in I/O space unconditionally.

However, this wasn't a problem as many other OSes' virtio PCI driver will automatically detect the bar type and issue the appropriate R/W command. For example in Linux, the pci_iomap will first find the bar type of the corresponding bar, so the driver itself does not take care of the bar type of bar0. And in Illumos, the situation is similar in rootnex_map(). More importantly, this potentially allows Arm to be supported as Arm is incapable of doing PIO unlike on x86.