OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [virtio-dev] [RFC] Add polling mode feature bit

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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]