Discussion of the implementations of VIRTIO specification
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Conghui Chen <conghui.chen@intel.com>
Cc: virtio-dev@lists.oasis-open.org, shuo.a.liu@intel.com,
	yu1.wang@intel.com
Subject: Re: [virtio-dev] [RFC] Add polling mode feature bit
Date: Tue, 25 Jun 2019 13:27:39 +0200	[thread overview]
Message-ID: <a95c6de2-212d-e034-d4e6-dc476917f62f@redhat.com> (raw)
In-Reply-To: <20190625191742.GA22520@intel.com>

On 25/06/19 21:17, Conghui Chen wrote:
> On Tue 25.Jun'19 at  9:32:13 +0200, Paolo Bonzini wrote:
>> On 25/06/19 17:15, Conghui Chen wrote:
>>> Hi,
>>>
>>> We are working on enable VIRTIO on RTVMs. For RT requirements and some
>>> security reasons, the VIRTIO interrupts are not allowed to inject to
>>> guest OS, and the notify flow may bring some uncertain delay, so the
>>> polling mode for VIRTIO device is taken into consideration. And in some
>>> open source projects, like DPDK and OVMF, the polling mode is
>>> implemented on device level, but if a system need all the VIRTIO devices
>>> work on polling mode, then we should support it for each VIRTIO device
>>> type. That will take lots of effort and may not able to upstream, such
>>> as in RT-Linux. So, we wonder that, if we could support polling mode on
>>> VIRTIO framework level?
>>>
>>> We have a proposal:
>>> Add a new feature bit: VIRTIO_F_PMD(39)
>>> This feature indicates that the driver should work in polling mode, and
>>> the device will not inject interrupt to Guest OS.
>>
>> How would it work?  Is this a feature that, if acknowledged by the
>> driver, causes the device to disable all interrupts?  It's quite
>> possible that there are drivers in the wild that blindly accept all
>> features proposed by the device, and which would break with such a
>> feature.
>>
> Hi Paolo,
> 
> I'm not sure if my understand is correct.
> The case you mentioned, the FE driver accept all feature bits without
> checking. I felt that it is incorrect behavior... As there is
> description in VIRTIO spec that driver MUST read device feature bits,
> and write the subset of feature bits understood by the OS and driver to
> the device. BE export new feature bits shouldn't depend on any FE driver
> changes, otherwise the new features will cause unexpected behaviors.

It is indeed incorrect.  VIRTIO_F_VERSION_1 is probably not the best
example, because virtio 0.9 only had room for 32 feature bits.  But
packed virtqueues certainly would break  existing drivers, so there is a
precedent.

Thanks!

Paolo

---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org


      reply	other threads:[~2019-06-25 11:27 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-25 15:15 [virtio-dev] [RFC] Add polling mode feature bit Conghui Chen
2019-06-25  7:32 ` Paolo Bonzini
2019-06-25 19:17   ` Conghui Chen
2019-06-25 11:27     ` Paolo Bonzini [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=a95c6de2-212d-e034-d4e6-dc476917f62f@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=conghui.chen@intel.com \
    --cc=shuo.a.liu@intel.com \
    --cc=virtio-dev@lists.oasis-open.org \
    --cc=yu1.wang@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox