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

Hi Demi,

> On 13 Feb 2026, at 20:45, Demi Marie Obenour <[email protected]> wrote:
>
> On 2/13/26 08:52, Parav Pandit 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.
>
> I recommend using a 64-bit or even 128-bit number.  This allows
> ensuring that device IDs are unique for the life of a VM or even
> globally, making reasoning about device identity simpler.

I will look into that but have a 128-bit number might introduce an header to big for some environments
where the maximum message size is constrained (FF-A with direct message is constrained to 120 bytes,
use cases using an hardware messaging system might also be constrained) so i will dig a bit to see the
consequences.

Now preventing to reuse the device ID could definitely solve some potential issues and apparently there
are also use cases with a great number of devices that we need to cover.

64-bit should be possible and i will check if we could have some provision for 128-bit.

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.