Closed cuinutanix closed 7 years ago
the register value in the trace seems to be disabling io/mem too? that could be pci-device-disable in board-qemu/slof/pci-device_1af4_1004.fs
i wonder if simply removing the pci-device-disable from that file allow the boot to continue?
No it doesn't. It just removes 1 call to pci-device-disable
but there are others, from pci-device.fs:
\ prepare the device for subsequent use
\ this word should be overloaded by the device file (if present)
\ the device file can call this file before implementing
\ its own open functionality
: open
puid >r \ save the old puid
my-puid TO puid \ set up the puid to the devices Hostbridge
pci-master-enable \ And enable Bus Master, IO and MEM access again.
pci-mem-enable \ enable mem access
pci-io-enable \ enable io access
r> TO puid \ restore puid
true
;
\ close the previously opened device
\ this word should be overloaded by the device file (if present)
\ the device file can call this file after its implementation
\ of own close functionality
: close
puid >r \ save the old puid
my-puid TO puid \ set up the puid
pci-device-disable \ and disable the device
r> TO puid \ restore puid
;
Node that the open
method enables the device, but that's not getting called.
OK, I think I figured it out, clue is in the comment:
\ prepare the device for subsequent use
\ this word should be overloaded by the device file (if present)
\ the device file can call this file before implementing
\ its own open functionality
virtio-scsi.fs does not have the "open" word.
Closing as per previous comment.
After SLOF successfully probes scsi disks on a virtio-scsi controller, it sends a write to the
PCI_COMMAND
register with value0x0
which disables the PCI device, which qemu translates tovirtio_set_status(vdev, vdev->status & ~VIRTIO_CONFIG_S_DRIVER_OK);
which tells the vhost backend that the driver wants the device stopped.qemu's own implementation of virtio-scsi seems to ignore the fact that the pci device is disabled, and will happily continue to process scsi requests from the ring, and guests are able to boot. However, with a vhost-scsi backend, qemu tells the vhost backend to stop processing the ring, and the guest does not boot.
Here is a gdb stack trace of when qemu disables the vhost-scsi device:
You would need to set up vhost-scsi in order to reproduce the exact same issue. You can observe that the
VIRTIO_CONFIG_S_DRIVER_OK
status bit being cleared even with a standard virtio-scsi backend by setting a breakpoint onvirtio_set_status()
and observe that the status goes from 0 to0xf
(fully functional), then after the bus scan completes, the status is set to0xb
, withVIRTIO_CONFIG_S_DRIVER_OK
cleared.