On Thu, 23 Jul 2020 11:13:55 -0400
Matthew Rosato <mjrosato@linux.ibm.com> wrote:
I noticed that after kernel commit abafbc55 'vfio-pci: Invalidate mmaps
and block MMIO access on disabled memory' vfio-pci via qemu on s390x
fails spectacularly, with errors in qemu like:
qemu-system-s390x: vfio_region_read(0001:00:00.0:region0+0x0, 4) failed:
Input/output error
From read to bar 0 originating out of hw/s390x/s390-pci-inst.c:zpci_read_bar().
So, I'm trying to figure out how to get vfio-pci happy again on s390x. From
a bit of tracing, we seem to be triggering the new trap in
__vfio_pci_memory_enabled(). Sure enough, if I just force this function to
return 'true' as a test case, things work again.
The included patch attempts to enforce the setting, which restores everything
to working order but also triggers vfio_bar_restore() in the process.... So
this isn't the right answer, more of a proof-of-concept.
@Alex: Any guidance on what needs to happen to make qemu-s390x happy with this
recent kernel change?
Bummer! I won't claim to understand s390 PCI, but if we have a VF
exposed to the "host" (ie. the first level where vfio-pci is being
used), but we can't tell that it's a VF, how do we know whether the
memory bit in the command register is unimplemented because it's a VF
or unimplemented because the device doesn't support MMIO? How are the
device ID, vendor ID, and BAR registers virtualized to the host? Could
the memory enable bit also be emulated by that virtualization, much
like vfio-pci does for userspace? If the other registers are
virtualized, but these command register bits are left unimplemented, do
we need code to deduce that we have a VF based on the existence of MMIO
BARs, but lack of memory enable bit? Thanks,