Re: [PATCH v1 0/4] virtio-msg transport layer

Hi Demi,

> On 25 Feb 2026, at 13:46, Demi Marie Obenour <[email protected]> wrote:
>
> On 2/25/26 02:52, Bertrand Marquis wrote:
>> Hi Parav,
>>
>>> On 25 Feb 2026, at 05:58, Parav Pandit <[email protected]> wrote:
>>>
>>>
>>>> From: Bertrand Marquis <[email protected]>
>>>> Sent: 20 February 2026 02:10 PM
>>>>
>>>> Hi Parav,
>>>>
>>>>> On 13 Feb 2026, at 14:52, Parav Pandit <[email protected]> wrote:
>>>>>
>>>>> Hi Bill,
>>>>>
>>>>>> From: Bill Mills <[email protected]>
>>>>>> Sent: 26 January 2026 10:02 PM
>>>>>>
>>>>>> This series adds the virtio-msg transport layer.
>>>>>>
>>>>>> The individuals and organizations involved in this effort have had difficulty in
>>>>>> using the existing virtio-transports in various situations and desire to add one
>>>>>> more transport that performs its transport layer operations by sending and
>>>>>> receiving messages.
>>>>>>
>>>>>> Implementations of virtio-msg will normally be done in multiple layers:
>>>>>> * common / device level
>>>>>> * bus level
>>>>>>
>>>>>> The common / device level defines the messages exchanged between the driver
>>>>>> and a device. This common part should lead to a common driver holding most
>>>>>> of the virtio specifics and can be shared by all virtio-msg bus implementations.
>>>>>> The kernel implementation in [3] shows this separation. As with other transport
>>>>>> layers, virtio-msg should not require modifications to existing virtio device
>>>>>> implementations (virtio-net, virtio-blk etc). The common / device level is the
>>>>>> main focus of this version of the patch series.
>>>>>>
>>>>>> The virtio-msg bus level implements the normal things a bus defines
>>>>>> (enumeration, dma operations, etc) but also implements the message send and
>>>>>> receive operations. A number of bus implementations are envisioned,
>>>>>> some of which will be reusable and general purpose. Other bus implementations
>>>>>> might be unique to a given situation, for example only used by a PCIe card
>>>>>> and its driver.
>>>>>>
>>>>>> The standard bus messages are an effort to avoid different bus implementations
>>>>>> doing the same thing in different ways for no good reason. However the
>>>>>> different environments will require different things. Instead of trying to
>>>>>> anticipate all needs and provide something very abstract, we think
>>>>>> implementation specific messages will be needed at the bus level. Over time,
>>>>>> if we see similar messages across multiple bus implementations, we will move to
>>>>>> standardize a bus level message for that.
>>>>>>
>>>>>
>>>>> I would review more, had first round of sparse review.
>>>>> Please find few comments/questions below.
>>>>>
>>>>> 1. device number should be 32-bit in struct virtio_msg_header.
>>>>> From SIOV_R2 experiences, we learnt that some uses have use case for more than 64k devices.
>>>>> Also mapping PCI BDF wont be enough in 16-bits considering domain field.
>>>>
>>>> That is a very interesting feedback, we will definitely take this into account.
>>>> We will have to decide how big and I will answer that in Demi's mail as there might be some drawbacks with
>>>> having very big sizes for the device ID.
>>>>
>>> I am slowly catching up on the thread.
>>> There are two types of device id needed.
>>> One is UUID style to uniquely identify the device that may show up using two transports to the driver.
>>> With that a driver can create single virtio_device object, which is reachable via two different transports.
>>> This offers performance, resiliency.
>>> This is likely a bigger string which is not efficient to use during every message transaction.
>>>
>>> Second one is: within a transport, a device id to identify the communication.
>>> I was referring to this device id to be u32, so that transport can support more than 64K devices.
>>
>> We will increase the device number size to support more than 64k devices.
>> For the UUID part, I feel it should be something provided as device information per device, so
>> we could add a non-mandatory field (nil-UUID when no ID available) and transfer that information
>> as part of GET_DEVICE_INFO.
>
> When would it not be available?

I am not aware of implementations assigned UUIDs per device.
In any case the field can always be there and the nil-UUID used if something does not have one.

>
>>>>> 7. VIRTIO_MSG_SET_VQUEUE does not have bit field for individual addresses.
>>>>
>>>> Set vqueue has an index to specify the virtqueue index but you have to specific all fields in one go that is true.
>>>> Do you need a solution where you could set some fields to a specific value to say "keep current" and only update part of the vqueue
>>>> configuration ?
>>>>
>>> I believe so, otherwise it cannot work with existing drivers without driver side caching them.
>>
>> I will investigate that possibility.
>
> With the current spec, adding virtqueues one at a time requires time
> quadratic in the number of virtqueues.  That's not good.

Solution i am looking at would still allow to transmit everything in one go but would leave it open
to only update/modify some specific fields (using an optional field mask to not modify some parts).

>
>>>>> This requires caching all the values on the driver side before sending the transport request.
>>>>> I think it is time for virtio spec to shift to virt queue create and destroy model using the admin queue interface.
>>>>> and no need to bring this VIRTIO_MSG_SET_VQUEUE legacy to new transport bindings.
>>>>> It may require more plumbing, but it is cleaner interface when a new transport binding is created.
>>>>
>>>> Admin queue useable with the message transport but I would be interested to understand exactly
>>>> the model you are referring to with create/destroy model.
>>>> Could you elaborate a bit so that i could understand what messages you would expect and how this would work ?
>>>>
>>> The suggestion is to not use SET_VQUEUE legacy.
>>> The suggestion is to use admin virtqueue to create queues and destroy queues, as they are merely an object.
>>> And new transport like your proposal can adapt to the modern style.
>>> So only admin queue configuration would be the only message.
>>> Rest of the other queues can be created directly using the admin queue.
>>
>> In a way, set vqueue message could be seen like that as it is a one time operation.
>> In most cases, drivers are configuring a virtqueue in one go which is optimized here
>> as we need only one message transfer.
>> If we include the proposal to also have an enable/disable directly in the message this
>> could allow for even less messages.
>>
>> Using the admin solution on top of virtio message is something possible and not prevented
>> by this solution.
>>
>> In my mind we have an object here as you create/destroy queues in one go and the fact
>> that a bus can transfer those requests asynchronously gives a solution equivalent to what
>> would be provided by admin vqueues.
>
> Why disadvantages does using admin vqueues have?

You need a virtqueue to use admin virtqueues so we need to have a solution to set this up.
Once there i agree you can use that instead but it would not change the fact that we need
a solution to setup a virtqueue.
Right now nothing is forbidding to use them, but we still need to have a way to configure vqueues
in the transport.

>
>>> One can say it is orthogonal feature and I agree with that reasoning.
>>> The part that bothers me is that the new transport ends up adding some legacy bits like set vqueue.
>>
>> We still need to support legacy to have existing implementation working and here we can optimize
>> them a bit by not transferring one message per field.
>
> Which existing implementations are you referring to?  It appears
> that these are mostly in embedded systems.  If they are shipped as
> a single unit, the drivers and devices could be updated at the same
> time and there is no need for backwards compatibility.

I am a bit lost here, do you mean we should or not have a solution to update individual fields ?
In any case the change i suggest would not remove the solution (preferred) to do everything
in one go (plus the possibiity to enable/disable the queue in the same message) but would
also allow ot update independent fields if wanted.

Cheers
Bertrand

> --
> Sincerely,
> Demi Marie Obenour (she/her/hers)<OpenPGP_0xB288B55FFF9C22C1.asc>


IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.