The ARM failure is because we're in a kernel transition.

Thanks @alyssais - your changes are fine and correct. I'm a little bit perplexed how this works in practice but I found this quote:

I/O space can be accessed differently on different platforms. Processors with special I/O instructions, like the Intel processor family, access the I/O space with in and out instructions. Machines without special I/O instructions will map to the address locations corresponding to the PCI host bridge in the host address domain. When the processor accesses the memory-mapped addresses, an I/O request will be sent to the PCI host bridge, which then translates the addresses into I/O cycles and puts them on the PCI bus.

I guess that because these are VFIO devices the real host bridge on the system takes care of all this.

Did you verify that I/O port BAR on that particular PCI device was required and working (e.g. with like a print statement in the QEMU code for the I/O bar region)

These are the two relevant functions - https://github.com/qemu/qemu/blob/master/hw/net/e1000e.c#L137-L183

I'll have a look.

I don't see those being called. It does have a non-zero size set though — that's how I ran into this.

I don't see those being called. It does have a non-zero size set though — that's how I ran into this.

The Linux driver only uses I/O port for certain device types:

	/* do not allocate ioport bars when not needed */
	need_ioport = e1000_is_need_ioport(pdev);
	if (need_ioport) {
		bars = pci_select_bars(pdev, IORESOURCE_MEM | IORESOURCE_IO);
		err = pci_enable_device(pdev);
	} else {
		bars = pci_select_bars(pdev, IORESOURCE_MEM);
		err = pci_enable_device_mem(pdev);
	}

QEMU advertises:

#define E1000_DEV_ID_82574L 0x10D3

Which isn't in the list:

static int e1000_is_need_ioport(struct pci_dev *pdev)
{
	switch (pdev->device) {
	case E1000_DEV_ID_82540EM:
	case E1000_DEV_ID_82540EM_LOM:
	case E1000_DEV_ID_82540EP:
	case E1000_DEV_ID_82540EP_LOM:
	case E1000_DEV_ID_82540EP_LP:
	case E1000_DEV_ID_82541EI:
	case E1000_DEV_ID_82541EI_MOBILE:
	case E1000_DEV_ID_82541ER:
	case E1000_DEV_ID_82541ER_LOM:
	case E1000_DEV_ID_82541GI:
	case E1000_DEV_ID_82541GI_LF:
	case E1000_DEV_ID_82541GI_MOBILE:
	case E1000_DEV_ID_82544EI_COPPER:
	case E1000_DEV_ID_82544EI_FIBER:
	case E1000_DEV_ID_82544GC_COPPER:
	case E1000_DEV_ID_82544GC_LOM:
	case E1000_DEV_ID_82545EM_COPPER:
	case E1000_DEV_ID_82545EM_FIBER:
	case E1000_DEV_ID_82546EB_COPPER:
	case E1000_DEV_ID_82546EB_FIBER:
	case E1000_DEV_ID_82546EB_QUAD_COPPER:
		return true;
	default:
		return false;
	}
}

What about trying ne2k-pci ? That seems to be only I/O bar based!

On aarch64 in the cloud-hypervisor guest I get:

ne2k-pci 0000:00:08.0: of_irq_parse_pci: failed with rc=-22

On x86_64, it doesn't work either, but for a different reason. This is printed repeatedly:

ne2k-pci 0000:00:08.0 eth0: NETDEV WATCHDOG: CPU: 0: transmit queue 0 timed out 892 ms

It does work on the cloud-hypervisor host (the QEMU guest).

On aarch64 in the cloud-hypervisor guest I get:

ne2k-pci 0000:00:08.0: of_irq_parse_pci: failed with rc=-22

On x86_64, it doesn't work either, but for a different reason. This is printed repeatedly:

ne2k-pci 0000:00:08.0 eth0: NETDEV WATCHDOG: CPU: 0: transmit queue 0 timed out 892 ms

It does work on the cloud-hypervisor host (the QEMU guest).

Ah - I can see it uses INTx - rather than MSI!

Because I was already testing it — if I replace Cloud Hypervisor with QEMU, it does work on aarch64.

Because I was already testing it — if I replace Cloud Hypervisor with QEMU, it does work on aarch64.

It's probably because it requires INTx interrupts - not something we support (or maybe we did add support but weren't able to test it regularly!)