All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcel Apfelbaum <marcel@redhat.com>
To: Laurent Vivier <lvivier@redhat.com>,
	qemu-devel qemu-devel <qemu-devel@nongnu.org>
Cc: Jason Wang <jasowang@redhat.com>,
	Eduardo Habkost <ehabkost@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Qemu-devel] "x-disable-pcie" virtio-pci property in compat_props (HW_COMPAT_2_4)
Date: Wed, 10 Feb 2016 11:52:36 +0200	[thread overview]
Message-ID: <56BB0864.5080701@redhat.com> (raw)
In-Reply-To: <56BA240A.6060409@redhat.com>

On 02/09/2016 07:38 PM, Laurent Vivier wrote:
> Hi,
>
> I'm playing with a qemu-2.5.0 and pc-i440fx-2.4 machine type, and
> perhaps I don't understand correctly the compat_props machinery but
> there is something strange for me:
>
> in qemu-2.5.0, hw/virtio/virtio-pci.c:
>
>     1880     DEFINE_PROP_BIT("x-disable-pcie", VirtIOPCIProxy, flags,
>     1881                     VIRTIO_PCI_FLAG_DISABLE_PCIE_BIT, false),
>
> So I guess a new default machine (pc-i440fx-2.5) will be defined by
> default with "x-disable-pcie" set to "false".

Correct, but we are talking about both pc and q35.
By default, virtio devices *can be* PCIe for all new machines.

>
> and in qemu-2.5, include/hw/compat.h:
>
>        3
>        4 #define HW_COMPAT_2_4 \
>        5         {\
> ..
>       14             .driver   = "virtio-pci",\
>       15             .property = "x-disable-pcie",\
>       16             .value    = "on",\
>       17         },{\
>
> So I guess a new machine pc-i440fx-2.4 created with qemu-2.5.0 will have
> "x-disable-pcie" set to true (as with qemu-2.4.0 this feature is not
> available).

Exactly, machines before 2.5 will not have virtio devices PCIe
Old q35 machines are also included.

>
> But in this case "x-disable-pcie" is always set to "false".

For older machines yes, for newer no.

>
> So the questions are:
> - do I understand correctly?

Does the above respond to your question?

> - I check "x-disable-pcie" for "virtio-*-pci" devices (virtio-net-pci,
> virtio-balloon-pci, ..."), should they inherit the behavior from their
> parent "virtio-pci"? (they should, as virtio-pci is an abstract device type)

Yes, they do inherit this property.

>
> My test:
>
> - take qemu-2.5.0 (a8c40fa Update version for v2.5.0 release)
> - start it with "-M pc-i440fx-2.5 -device virtio-balloon-pci -S",
>    "info qtree":
>
>      bus: pci.0
>        type PCI
>        dev: virtio-balloon-pci, id ""
> ...
>          x-disable-pcie = false

This is correct again.

>
> - start it with "-M pc-i440fx-2.4 -device virtio-balloon-pci -S",
>    "info qtree":
>
>      bus: pci.0
>        type PCI
>        dev: virtio-balloon-pci, id ""
> ...
>          x-disable-pcie = false

This is a bug! Thanks for finding it.
It took a little but I found the root cause.

We have 2 virtio features mapped into the same bit:
- #define VIRTIO_PCI_FLAG_MIGRATE_EXTRA_BIT 4
- #define VIRTIO_PCI_FLAG_DISABLE_PCIE_BIT 4

Since both properties appear in HW_COMPAT_2_4, but
migrate-extra is the last one used, it wins the race.


To the obvious question of "how did that happen?" I can say we had an unlucky break.
Both Jason and me worked on a new different virtio feature in the same time,
and they were both merged in the same pull request.
We both saw BIT 3 as the last used :)

https://lists.gnu.org/archive/html/qemu-devel/2015-11/msg03041.html

I'll send a patch to map virtio pcie feature to a different  bit.
Thanks,
Marcel


>
> Any explanation is very welcome.
>
> Thanks,
> Laurent
>

  reply	other threads:[~2016-02-10  9:52 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-09 17:38 [Qemu-devel] "x-disable-pcie" virtio-pci property in compat_props (HW_COMPAT_2_4) Laurent Vivier
2016-02-10  9:52 ` Marcel Apfelbaum [this message]
2016-02-10 10:09   ` Laurent Vivier

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=56BB0864.5080701@redhat.com \
    --to=marcel@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=jasowang@redhat.com \
    --cc=lvivier@redhat.com \
    --cc=mst@redhat.com \
    --cc=qemu-devel@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.