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

[Demi Marie Obenour <demiobenour@gmail.com>]

[-- Attachment #1.1.1: Type: text/plain, Size: 7208 bytes --]

On 2/25/26 02:52, Bertrand Marquis wrote:
> Hi Parav,
> 
>> On 25 Feb 2026, at 05:58, Parav Pandit <parav@nvidia.com> wrote:
>>
>>
>>> From: Bertrand Marquis <Bertrand.Marquis@arm.com>
>>> Sent: 20 February 2026 02:10 PM
>>>
>>> Hi Parav,
>>>
>>>> On 13 Feb 2026, at 14:52, Parav Pandit <parav@nvidia.com> wrote:
>>>>
>>>> Hi Bill,
>>>>
>>>>> From: Bill Mills <bill.mills@linaro.org>
>>>>> 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?

>>>> 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.

>>>> 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?

>> 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.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]