All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Vivier <lvivier@redhat.com>
To: Marcel Apfelbaum <marcel@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:09:07 +0100	[thread overview]
Message-ID: <56BB0C43.2070800@redhat.com> (raw)
In-Reply-To: <56BB0864.5080701@redhat.com>



On 10/02/2016 10:52, Marcel Apfelbaum wrote:
> 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,

Thank you Marcel!

You have answered to all my questions and find a fix. This is perfect :)

Laurent

      reply	other threads:[~2016-02-10 10:09 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
2016-02-10 10:09   ` Laurent Vivier [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=56BB0C43.2070800@redhat.com \
    --to=lvivier@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=jasowang@redhat.com \
    --cc=marcel@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.