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

Demi Marie Obenour <[email protected]> Wed, 25 Feb 2026 08:09:56 -0500
Newsgroups	dev.linux.lists.virtio-comment
Message-ID	<[email protected]>
On 2/25/26 08:05, Bertrand Marquis wrote:
> 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.

I expect that the UUID will be set out of band by the management stack.

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

Please ignore this comment.  I didn't read the part about the virtqueue index.

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

Oh, that makes sense.

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

I meant being able to update individual virtqueues, as opposed to
having to setup all virtqueues at once.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
OpenPGP_0xB288B55FFF9C22C1.asc (application/pgp-keys, 7 KB)
OpenPGP_signature.asc (application/pgp-signature, 833 B)