All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Greg Kurz <gkurz@linux.vnet.ibm.com>
Cc: qemu-devel@nongnu.org, Anthony Liguori <aliguori@amazon.com>,
	qemu-stable@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v2] virtio-pci: enable bus master for old guests
Date: Thu, 11 Sep 2014 20:52:22 +0300	[thread overview]
Message-ID: <20140911175222.GB28605@redhat.com> (raw)
In-Reply-To: <20140911180039.2c3df0d2@bahia.local>

On Thu, Sep 11, 2014 at 06:00:39PM +0200, Greg Kurz wrote:
> On Wed, 10 Sep 2014 20:30:47 +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 when driver discovers device.
> > 
> > Cc: qemu-stable@nongnu.org
> > Reported-by: Greg Kurz <gkurz@linux.vnet.ibm.com>
> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > ---
> > 
> > OK, this should have better luck.
> 
> Unfortunately not... it is even worse than V1 as
> both x86 and ppc64 guests fail. I've added some
> debug messages in virtio_ioport_write() and
> virtio_write_config() to track:
> - VIRTIO_PCI_STATUS changes
> - bus master disablement
> 
> This is what I get for x86 with a virtio-net device:
> 
> virtio_write_config: PCI_COMMAND = 0x3
> virtio_ioport_write: VIRTIO_PCI_STATUS = 0x0
> virtio_ioport_write: VIRTIO_PCI_STATUS = 0x1 ==> v2 patch enables BM
> virtio_ioport_write: VIRTIO_PCI_STATUS = 0x3
> virtio_write_config: PCI_COMMAND = 0x3       ==> guest disables BM
> virtio_ioport_write: VIRTIO_PCI_STATUS = 0x7
> virtio_ioport_write: detected bus master bug ==> v1 patch would have
>                                                  enabled BM here
> 
> and for ppc64 when booting from a virtio-blk disk:
> 
> virtio_write_config: PCI_COMMAND = 0x3
> virtio_ioport_write: VIRTIO_PCI_STATUS = 0x0
> virtio_ioport_write: VIRTIO_PCI_STATUS = 0x1 ==> v2 patch enables BM
> virtio_ioport_write: VIRTIO_PCI_STATUS = 0x3
> virtio_write_config: PCI_COMMAND = 0x3       ==> guest disables BM


So guest sets DRIVER then overwrites PCI_COMMAND.  Weird.
Any idea which guest code does this?

> I think we should:
> - detect the "old driver" when reaching DRIVER as it works for
>   both architectures
> - always re-enable BM when an "old driver" disables it
> 
> That is basically your v1 plus its follow-up patch:
> 
> https://lists.nongnu.org/archive/html/qemu-devel/2014-09/msg01918.html
> 
> plus:
> 
> --- a/hw/virtio/virtio-pci.c
> +++ b/hw/virtio/virtio-pci.c
> @@ -317,7 +317,7 @@ static void virtio_ioport_write(void *opaque, uint32_t addr, uint32_t val)
>          /* Linux before 2.6.34 sets the device as OK without enabling
>             the PCI device bus master bit. In this case we need to disable
>             some safety checks. */
> -        if ((val & VIRTIO_CONFIG_S_DRIVER_OK) &&
> +        if ((val & VIRTIO_CONFIG_S_DRIVER) &&
>              !(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,
> 
> I could verify it fixes the issues. I will send a patch shortly.
> 
> 
> Cheers.
> 
> --
> Greg
> 
> > This also makes it possible to simplify code,
> > will do that in a follow-up patch.
> > 
> > 
> >  hw/virtio/virtio-pci.c | 8 ++++++++
> >  1 file changed, 8 insertions(+)
> > 
> > diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
> > index ddb5da1..a29d94f 100644
> > --- a/hw/virtio/virtio-pci.c
> > +++ b/hw/virtio/virtio-pci.c
> > @@ -303,6 +303,14 @@ static void virtio_ioport_write(void *opaque, uint32_t addr, uint32_t val)
> >              virtio_pci_stop_ioeventfd(proxy);
> >          }
> > 
> > +        /* Linux before 2.6.34 uses the device without enabling
> > +           the PCI device bus master bit. As a work-around, enable it
> > +           automatically when driver detects the device. */
> > +        if (val == VIRTIO_CONFIG_S_ACKNOWLEDGE) {
> > +            memory_region_set_enabled(&proxy->pci_dev.bus_master_enable_region,
> > +                                      true);
> > +        }
> > +
> >          virtio_set_status(vdev, val & 0xFF);
> > 
> >          if (val & VIRTIO_CONFIG_S_DRIVER_OK) {

      parent reply	other threads:[~2014-09-11 17:49 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-10 17:30 [Qemu-devel] [PATCH v2] virtio-pci: enable bus master for old guests Michael S. Tsirkin
2014-09-11 16:00 ` Greg Kurz
2014-09-11 16:49   ` Michael S. Tsirkin
2014-09-11 17:52   ` Michael S. Tsirkin [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140911175222.GB28605@redhat.com \
    --to=mst@redhat.com \
    --cc=aliguori@amazon.com \
    --cc=gkurz@linux.vnet.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-stable@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.