All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcel Apfelbaum <marcel@redhat.com>
To: Cornelia Huck <cornelia.huck@de.ibm.com>,
	Maxime Coquelin <maxime.coquelin@redhat.com>
Cc: mst@redhat.com, qemu-devel@nongnu.org, vkaplans@redhat.com,
	qemu-stable@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 1/2] virtio: Add backend feature testing functionnality
Date: Fri, 9 Sep 2016 13:48:00 +0300	[thread overview]
Message-ID: <c5ec8e2d-bed6-06d7-0bef-cd4df41692a5@redhat.com> (raw)
In-Reply-To: <20160909123348.4779e59c.cornelia.huck@de.ibm.com>

On 09/09/2016 01:33 PM, Cornelia Huck wrote:
> On Fri,  9 Sep 2016 12:14:31 +0200
> Maxime Coquelin <maxime.coquelin@redhat.com> wrote:
>
>> This patch adds virtio_test_backend_feature() function to
>> enable checking a backend feature before the negociation
>> takes place.
>>
>> It may be used, for example, to check whether the backend
>> supports VIRTIO_F_VERSION_1 before enabling modern
>> capabilities.
>>
>> Cc: Marcel Apfelbaum <marcel@redhat.com>
>> Cc: Michael S. Tsirkin <mst@redhat.com>
>> Cc: qemu-stable@nongnu.org
>> Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
>> ---
>>  hw/virtio/virtio.c         | 14 ++++++++++++++
>>  include/hw/virtio/virtio.h |  2 ++
>>  2 files changed, 16 insertions(+)
>>
>> diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
>> index 74c085c..7ab91a1 100644
>> --- a/hw/virtio/virtio.c
>> +++ b/hw/virtio/virtio.c
>> @@ -1481,6 +1481,20 @@ void virtio_vmstate_save(QEMUFile *f, void *opaque, size_t size)
>>      virtio_save(VIRTIO_DEVICE(opaque), f);
>>  }
>>
>> +bool virtio_test_backend_feature(VirtIODevice *vdev,
>> +                                 unsigned int fbit, Error **errp)
>> +{
>> +    VirtioDeviceClass *k = VIRTIO_DEVICE_GET_CLASS(vdev);
>> +    uint64_t feature;
>> +
>> +    virtio_add_feature(&feature, fbit);
>> +
>> +    assert(k->get_features != NULL);
>> +    feature = k->get_features(vdev, feature, errp);
>> +
>> +    return virtio_has_feature(feature, fbit);
>> +}
>> +
>>  static int virtio_set_features_nocheck(VirtIODevice *vdev, uint64_t val)
>>  {
>>      VirtioDeviceClass *k = VIRTIO_DEVICE_GET_CLASS(vdev);
>
> What happens if you want to test for features that depend upon each
> other? The backend may support your feature, but it may withdraw the
> feature bit if a dependency is not fullfilled.
>
> You'll probably want to run validation on the whole feature set; but
> that is hard if you're too early in the setup process.
>

While I agree with the feature dependency issue , would the negation be ok?
What I mean is: if the backend does not support feature X, no
matter what the depending features are, it will still not support it after the negotiation.

Changing the function to virtio_backend_unsupported_feature(x) would be better?

Thanks,
Marcel

  reply	other threads:[~2016-09-09 10:48 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-09 10:14 [Qemu-devel] [PATCH 0/2] virtio-pci: Improve device plugging whith legacy backends Maxime Coquelin
2016-09-09 10:14 ` [Qemu-devel] [PATCH 1/2] virtio: Add backend feature testing functionnality Maxime Coquelin
2016-09-09 10:33   ` Cornelia Huck
2016-09-09 10:48     ` Marcel Apfelbaum [this message]
2016-09-09 10:55       ` Cornelia Huck
2016-09-09 11:02         ` Marcel Apfelbaum
2016-09-09 11:20           ` Cornelia Huck
2016-09-09 11:36             ` Maxime Coquelin
2016-09-09 11:47               ` Marcel Apfelbaum
2016-09-09 10:14 ` [Qemu-devel] [PATCH 2/2] virtio-pci: Disable modern interface if backend without VIRTIO_F_VERSION_1 Maxime Coquelin
2016-09-09 10:40   ` Cornelia Huck
2016-09-09 11:04     ` Marcel Apfelbaum
2016-09-09 11:20       ` Cornelia Huck
2016-09-09 11:44         ` Maxime Coquelin
2016-09-09 11:49           ` Cornelia Huck
2016-09-09 12:01             ` Maxime Coquelin
2016-09-09 14:14             ` [Qemu-devel] [RFC] virtio-bus: Plug devices after features are negotiated Maxime Coquelin
2016-09-09 15:39               ` Michael S. Tsirkin
2016-09-09 16:16                 ` Maxime Coquelin
2016-09-09 18:44                   ` Michael S. Tsirkin

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=c5ec8e2d-bed6-06d7-0bef-cd4df41692a5@redhat.com \
    --to=marcel@redhat.com \
    --cc=cornelia.huck@de.ibm.com \
    --cc=maxime.coquelin@redhat.com \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-stable@nongnu.org \
    --cc=vkaplans@redhat.com \
    /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.