Re: [Qemu-devel] [PATCH] virtio-pci: enable bus master for old guests

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Sep 10, 2014 at 12:35:32AM +0200, Greg Kurz wrote:
> On Mon, 8 Sep 2014 19:05:02 +0300
> "Michael S. Tsirkin" <mst@redhat.com> wrote:
> 
> > commit cc943c36faa192cd4b32af8fe5edb31894017d35
> >     pci: Use bus master address space for delivering MSI/MSI-X messages
> > breaks virtio-net for rhel6.[56] x86 guests because they don't
> > enable bus mastering for virtio PCI devices
> > 
> > Old guests forgot to enable bus mastering, enable it
> > automatically on DRIVER_OK.
> > 
> > Note: we should either back out the original patch from
> > stable or apply this one on top.
> > 
> > Cc: qemu-stable@nongnu.org
> > Reported-by: Greg Kurz <gkurz@linux.vnet.ibm.com>
> > Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > ---
> >  hw/virtio/virtio-pci.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
> > index ddb5da1..af937d2 100644
> > --- a/hw/virtio/virtio-pci.c
> > +++ b/hw/virtio/virtio-pci.c
> > @@ -320,6 +320,8 @@ static void virtio_ioport_write(void *opaque, uint32_t addr, uint32_t val)
> >          if ((val & VIRTIO_CONFIG_S_DRIVER_OK) &&
> >              !(proxy->pci_dev.config[PCI_COMMAND] & PCI_COMMAND_MASTER)) {
> >              proxy->flags |= VIRTIO_PCI_FLAG_BUS_MASTER_BUG;
> > +            memory_region_set_enabled(&proxy->pci_dev.bus_master_enable_region,
> > +                                      true);
> >          }
> >          break;
> >      case VIRTIO_MSI_CONFIG_VECTOR:
> 
> Cc'ing Alexey for some SLOF and early boot of the ppc64 kernel expertise.
> 
> Michael,
> 
> This was enough to fix virtio-net in the rhel6.5 x86 guest case. Unfortunately,
> this fails for rhel6.5 ppc64 because it is never called... I did some debugging:
> it looks like the guest kernel calls the OF quisece call to flush pending DMA
> and disables bus master on the virtio-blk device (PCI_COMMAND == 0x3). The
> guest then continues to boot and hangs... It appears that waiting for the
> guest to issue VIRTIO_CONFIG_S_DRIVER_OK is not enough.

Got it. Writing to PCI_COMMAND disabled bus mastering again.
This should do it, on top - can you confirm please?

diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index af937d2..6b7ac39 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -475,10 +475,14 @@ static void virtio_write_config(PCIDevice *pci_dev, uint32_t address,
     pci_default_write_config(pci_dev, address, val, len);
 
     if (range_covers_byte(address, len, PCI_COMMAND) &&
-        !(pci_dev->config[PCI_COMMAND] & PCI_COMMAND_MASTER) &&
-        !(proxy->flags & VIRTIO_PCI_FLAG_BUS_MASTER_BUG)) {
-        virtio_pci_stop_ioeventfd(proxy);
-        virtio_set_status(vdev, vdev->status & ~VIRTIO_CONFIG_S_DRIVER_OK);
+        !(pci_dev->config[PCI_COMMAND] & PCI_COMMAND_MASTER)) {
+        if (proxy->flags & VIRTIO_PCI_FLAG_BUS_MASTER_BUG) {
+            memory_region_set_enabled(&proxy->pci_dev.bus_master_enable_region,
+                                      true);
+        } else {
+            virtio_pci_stop_ioeventfd(proxy);
+            virtio_set_status(vdev, vdev->status & ~VIRTIO_CONFIG_S_DRIVER_OK);
+        }
     }
 }