On Wed, Oct 17, 2018 at 10:47:40AM +0100, Stefan Hajnoczi wrote:
> On Tue, Oct 16, 2018 at 06:27:12PM +0300, Roman Bolshakov wrote:
> >
> > It looks like virtio backend doesn't return 0 device status after
> > vp_iowrite8 and vp_reset blocks udev:
> > while (vp_ioread8(&vp_dev->common->device_status))
> > msleep(1)
> >
> > What could be the cause of the issue?
> > Any advices how to triage it are appreciated.
>
> I wonder what happened in virtio_pci_probe() ->
> virtio_pci_modern_probe(). For example, were the BARs properly set up?
>
> For starters you can debug the QEMU process to check if
> virtio_pci_common_read/write() get called for this device (disable all
> other virtio devices to make life easy). If these functions aren't
> being called then the guest either got the address wrong or dispatch
> isn't working for some other reason (hvf?).
>
Thank you Stefan. That explains why it doesn't quit:
virtio_pci_common_write: hwaddr 0x14 val 0x8 size 0x1
38552@1539791595.072718:virtio_set_status vdev 0x7f92d5ef4170 val 8
virtio_pci_common_read: hwaddr 0x14 val 0x8 size 0x1
virtio_pci_common_read: hwaddr 0x14 val 0x8 size 0x1
virtio_pci_common_read: hwaddr 0x14 val 0x8 size 0x1
virtio_pci_common_read: hwaddr 0x14 val 0x8 size 0x1
virtio_pci_common_read: hwaddr 0x14 val 0x8 size 0x1
virtio_pci_common_read: hwaddr 0x14 val 0x8 size 0x1
I executed QEMU a number of times, each time vpirtio_pci_common_write
writes different value but virtio_pci code clearly writes 0:
/* 0 status means a reset. */
vp_iowrite8(0, &vp_dev->common->device_status);
Maybe the value somehow got corrupted or it was taken from wrong location.
-Roman
