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

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

[Paolo Bonzini]

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.

Paolo

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

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

[Paolo Bonzini]

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

[virtio-dev] [RFC] Add polling mode feature bit

[Conghui Chen]

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.

Regards,
Conghui.


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

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

[Conghui Chen]

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.
Such as the feature bit VIRTIO_F_VERSION_1, if the FE driver not support
it but accept it, the driver will also break with this feature.

Blindly accept all features will cause any future new BE export features
can not depend on any FE driver changes, otherwise the new features will
cause unexpected behaviors.
Such as the feature bit VIRTIO_F_VERSION_1, if the FE driver not support
it but accept it, the driver will also break with this feature.

Regards,
Conghui.

>Paolo

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