[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v1 2/8] virtio-pci: Lock ioeventfd state with VIRTIO_F_NOTIFI

From: Jonah Palmer
Subject: Re: [PATCH v1 2/8] virtio-pci: Lock ioeventfd state with VIRTIO_F_NOTIFICATION_DATA
Date: Tue, 12 Mar 2024 10:33:51 -0400
User-agent: Mozilla Thunderbird

On 3/11/24 11:47 AM, Michael S. Tsirkin wrote:
On Mon, Mar 11, 2024 at 10:53:25AM -0400, Jonah Palmer wrote:

On 3/8/24 2:19 PM, Michael S. Tsirkin wrote:
On Fri, Mar 08, 2024 at 12:45:13PM -0500, Jonah Palmer wrote:

On 3/8/24 12:36 PM, Eugenio Perez Martin wrote:
On Fri, Mar 8, 2024 at 6: 01 PM Michael S. Tsirkin <mst@ redhat. com>
wrote: > > On Mon, Mar 04, 2024 at 02: 46: 06PM -0500, Jonah Palmer
wrote: > > Prevent ioeventfd from being enabled/disabled when a
virtio-pci > > device
This Message Is From an External Sender
This message came from outside your organization.
Report Suspicious

On Fri, Mar 8, 2024 at 6:01 PM Michael S. Tsirkin <mst@redhat.com> wrote:

On Mon, Mar 04, 2024 at 02:46:06PM -0500, Jonah Palmer wrote:
Prevent ioeventfd from being enabled/disabled when a virtio-pci
device has negotiated the VIRTIO_F_NOTIFICATION_DATA transport

Due to ioeventfd not being able to carry the extra data associated with
this feature, the ioeventfd should be left in a disabled state for
emulated virtio-pci devices using this feature.

Reviewed-by: Eugenio Pérez <eperezma@redhat.com>
Signed-off-by: Jonah Palmer <jonah.palmer@oracle.com>

I thought hard about this. I propose that for now,
instead of disabling ioevetfd silently we error out unless
user disabled it for us.

Yes, error is a better plan than silently disabling it. In the
(unlikely?) case we are able to make notification data work with
eventfd in the future, it makes the change more evident.

Will do in v2. I assume we'll also make this the case for virtio-mmio and

Guess so. Pls note freeze is imminent.

Got it. Also, would you mind elaborating a bit more on "error out"? E.g. do
we want to prevent the Qemu from starting at all if a device is attempting
to use both VIRTIO_F_NOTIFICATION_DATA and ioeventfd? Or do you mean
something like still keep ioeventfd disabled but also log an error message
unless it was explicitly disabled by the user?

my preference would be to block device instance from being created.

I could very well be missing something here, but I was looking to see how I could block the device from being created (realized) given the functional mismatch between negotiating the VIRTIO_F_NOTIFICATION_DATA feature and ioeventfd being enabled.

However, I realized that feature negotiation only happens after the virtio device has been realized and it's one of the last steps before the device becomes fully operational. In other words, we don't know if the guest (driver) also supports this feature until the feature negotiation phase, which is after realization.

So, during realization (e.g. virtio_device_realize), we know if the virtio device (1) intends to negotiate the VIRTIO_F_NOTIFICATION_DATA feature and (2) has enabled ioeventfd, however, we don't know if the driver will actually support this notification data feature.

Given this, we could block the device from being created if the device is *intending* to use the notification data feature along with ioeventfd, but this seems premature since we don't know if the feature will actually be successfully negotiated.

Another option might be check this during/immediately after feature negotiation, and then unrealize the device. However, I'm not sure if by this point it's "too late" to unrealize it.

There's also other options like defaulting to using notification data over ioeventfd (since a user would need to explicitly enable it, showing intent to actually use the feature), which is what we're doing now, except we could add some kind of warning message for the user. Another option could be setting the device to broken. However, these options don't align with your suggestion of removing the device completely.

Let me know how you'd like me to proceed with this. Thanks!

   hw/virtio/virtio-pci.c | 6 ++++--
   1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index d12edc567f..287b8f7720 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -417,13 +417,15 @@ static void virtio_ioport_write(void *opaque, uint32_t 
addr, uint32_t val)
       case VIRTIO_PCI_STATUS:
-        if (!(val & VIRTIO_CONFIG_S_DRIVER_OK)) {
+        if (!(val & VIRTIO_CONFIG_S_DRIVER_OK) &&
+            !virtio_vdev_has_feature(vdev, VIRTIO_F_NOTIFICATION_DATA)) {

           virtio_set_status(vdev, val & 0xFF);

-        if (val & VIRTIO_CONFIG_S_DRIVER_OK) {
+        if ((val & VIRTIO_CONFIG_S_DRIVER_OK) &&
+            !virtio_vdev_has_feature(vdev, VIRTIO_F_NOTIFICATION_DATA)) {


reply via email to

[Prev in Thread] Current Thread [Next in Thread]