From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 92FD32FA0C7 for ; Thu, 19 Feb 2026 23:54:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771545298; cv=none; b=nlAhJ7d3c8DO1ajqeWMAJ5JXx3EGpweBx4IQAGltZcH0bkE5NxoLQ1NLHaCkWqc1dD4uobiIx3s6HYzqoFNSneyEpozKO8acS28NTEfdVXqL19jCB+fWHurOtOqhWGHZ/FI5EVagKvywZDfIOGFELrRSR3vr+iIdD/oJbDa1uMM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771545298; c=relaxed/simple; bh=FUuQLQIxA6gqfIzHIXPGHzmtkVsLxk+BtEadLBlFuaY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: In-Reply-To:Content-Type:Content-Disposition; b=n5uCC1mTL7Y5n3XmRu0SQpuWtzJBUgcnq3B7XG6KbrCPapkPRgPGE8IKpiOD/+jQBo8NYwAmvZoNhzgduKzlSHcI9vMtxhKuvqUcDqrgLZ9IMWOz9tYNusRepgbiOkBTQBjLzGpB/wXNeJeZj2Fjn3VKlOWI9VqsTogcPUffZpQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=AqBfC35r; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="AqBfC35r" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1771545294; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=GNsdMqAN7fA8LARKJeZ0aRyp0P/hX2caNnJZIKiWF44=; b=AqBfC35rz5+HH5lvxmrOe99QurB9+uuu/TYBDhx813PRpDJjTVpDA5p1T6cSJWiLRe3ihv 8Eg3gBGPh7Z6vj60YXoO7BpwouMnnSLpUTdUvJH/g/7uktVTZNm1mGuruAv24NyOCIfLxx BcbsdY6lLn4MUX26PigvnX/RWINmnFo= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-676-7je0KSeVOcq2HVJu1P5G1A-1; Thu, 19 Feb 2026 18:54:53 -0500 X-MC-Unique: 7je0KSeVOcq2HVJu1P5G1A-1 X-Mimecast-MFC-AGG-ID: 7je0KSeVOcq2HVJu1P5G1A_1771545292 Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-4836abfc742so10143795e9.0 for ; Thu, 19 Feb 2026 15:54:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771545292; x=1772150092; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=GNsdMqAN7fA8LARKJeZ0aRyp0P/hX2caNnJZIKiWF44=; b=hFU2ngJOr53wv3QScFnVjiZShYjUSYfTvWWsTWX2nvNkxLQvcrzKaaCBAZRnKgRmo/ EAFF+XCHGd2u360n1zRN1XQAwF8v4ZkzLAf8RPCWTg8U6OSmz6m7cVf4V6zrKlk09Xpo q5QNoFK2QrTyklIBfrWLyJu/9yg5lD1+6RPVKixy8ZAE98tSFA7hxLao+YNK4BTIf9Gm mH3VP4Kwp/QiHKqcfp5sSNgNqOdGcsa0A2PEMOaK75GukwAhXz9VRsWkzA4VVoS1ih50 chjob4rXzQ6B1xK2hEjM7aXd2IwQOK6IJop7qMp6E3h8GkmivDb2XIPD+gmxGzkT/9FU e+og== X-Forwarded-Encrypted: i=1; AJvYcCWmLB4bNEXz4wKy7zVGMrQvENoTs4J7wjXnAra6czA33viBQvPSZSfCGVlQ66deK4UUFexZF/kQ1bJ/6JppOw==@lists.linux.dev X-Gm-Message-State: AOJu0YwznMQEIvYyYWYCZhSjykYA50K6U+fqekEhdV1I3QsNOp/WQlrT DOzffHMxO4BnQS/o3EJpX883eic6Gcucsi7zw8lRVeTuAIiccfRzxFbGAMHBXyceJevTmd8JMJm 0fhFmXivCaGpdGrwhEDR3+6QIc1IUyyVv73f5S7y7SbZGDbx/jHjKg93FAjeV0y4qguznIyStsA Kd X-Gm-Gg: AZuq6aLpx3e05efJbjRcgCUnlqaBvBV+3+rsjbzD1ow68RWpvnOgyfcTC56bnUXUZKa OHT47ZZD4LPIZ+95dsHtpAl9ffWydQkZ/cGAiL6zC3xhwjGMyONGHKEeMG4WyhpKNOvbCf8r+3U YDix2npsegogakc179hWIvXWyQDIpRTwU9vwjDs7W72poG7pFFUxbhU9RILiKfSjpGjzB3YmVJF Y6saTO227YI7vyHic0bQOIf1dGE4JacBTdcTpU3YLjW6Q9WAFHE1X5Vp/GM8tlu8hl12YfxvB1D YHnONq4OUWx7ol9fdDP11WYP5r6y0cmCeuCxx1dkOIRr5dIL1Q4jKPpYJfOFabTVEYsAnCwyL0T 9bS+gbyxkzGGTX5z7T/UkU0zOy7B1DnRWR5fDSjS1QdNpDg== X-Received: by 2002:a05:600c:444f:b0:475:de14:db1e with SMTP id 5b1f17b1804b1-48379bd742amr324283725e9.24.1771545291679; Thu, 19 Feb 2026 15:54:51 -0800 (PST) X-Received: by 2002:a05:600c:444f:b0:475:de14:db1e with SMTP id 5b1f17b1804b1-48379bd742amr324283355e9.24.1771545291065; Thu, 19 Feb 2026 15:54:51 -0800 (PST) Received: from redhat.com (IGLD-80-230-79-166.inter.net.il. [80.230.79.166]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-483a31c56d8sm56652795e9.8.2026.02.19.15.54.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 Feb 2026 15:54:50 -0800 (PST) Date: Thu, 19 Feb 2026 18:54:47 -0500 From: "Michael S. Tsirkin" To: Parav Pandit Cc: Bill Mills , "virtio-comment@lists.linux.dev" , Bertrand Marquis , "Edgar E . Iglesias" , Arnaud Pouliquen , Viresh Kumar , Alex Bennee , Armelle Laine Subject: Re: [PATCH v1 0/4] virtio-msg transport layer Message-ID: <20260219185034-mutt-send-email-mst@kernel.org> References: <20260126163230.1122685-1-bill.mills@linaro.org> Precedence: bulk X-Mailing-List: virtio-comment@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: E8mq8DPFV_pceuiDGN_MfiMKcl8NrGAvo2l7fWz5t0E_1771545292 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Feb 13, 2026 at 01:52:06PM +0000, Parav Pandit wrote: > Hi Bill, > > > From: Bill Mills > > 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. I'd like to comment that I think it makes sense to have a basic simple transport and then add performance features on top as appropriate. So one way to address some of these comments is to show how they can be addressed with a feature bit down the road. > 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. > > 2. msg_size of 16-bits for 64KB-8 bytes is too less for data transfer. > For example, a TCP stream wants to send 64KB of data + payload, needs more than 64KB data. > Needs 32-bits. > > 3. BUS_MSG_EVENT_DEVICE to have symmetric name as ADDED and REMOVED (instead of READY) > But more below. > > 4. I dont find the transport messages to read and write to the driver memory supplied in VIRTIO_MSG_SET_VQUEUE addresses to operate the virtqueues. > Dont we need VIRTIO_MEM_READ, VIRTIO_MEM_WRITE request and response? surely this can be an optional transport feature bit. > Also, the queue notification message is missing at bus level. > But I dont think queue notification via message good idea anyway. > We rather need a more higher-level message for virtqueues. > Such as posting the descriptors to device. And this should translate into a VIRTIO_MSG_DESC_SEND or bus specific binding. > Without this msg transport is incomplete. this too can be a basic method and upgrade to a different one with a feature negotiation > 5. msg_id to be renamed to msg_opcode, and token to be renamed to msg_id as it identifies the msg (as written in the description) in > > 6. Bus requirements ordering is too strict for implementing any performant data path as data response may not be in same order as request for reads. here too, relaxed ordering could be a feature bit. > 7. VIRTIO_MSG_SET_VQUEUE does not have bit field for individual addresses. > 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. > > 8. We should have the message response header for req-resp method with status code. > (even though they are plain MMIO writes for pci). > As opposed to that, proposed messages are doing composite tasks, hence we need the status response. > > 9. virtio stack cannot handle hotplug devices today, at least Linux. > So if the intention is to fit into such a system, DEVICE_BUS_STATE_REMOVED will not be enough. > A graceful method is needed. > > > We are working on a few reusable bus implementations: > > > > * virtio-msg-ffa based on Arm FF-A interface for use between: > > * normal world and secure world > > * host and VM or VM to VM > > * Can be used w/ or with out a hypervisor > > * Any Hypervisor that implements FF-A can be used > > * We have this working with pKVM and Xen > > * We have this working with Trusty and OP-TEE > > > > * virtio-msg-amp for use between heterogenous systems > > * The main processors and its co-processors on an AMP SOC > > * Two or more systems connected via PCIe > > * Minimal requirements: bi-directional interrupts and > > at least one shared memory area > > * hvac-demo has 2 demos of this > > * This is working on two hardware platforms > > > > * virtio-msg-loopback for userspace implemented devices > > * Allows user space to provide devices to its own kernel > > * This is similar to fuse, cuse or loopback block devices but for virtio > > * hvac-demo has a demo > > > > We also anticipate a few more: > > > > * virtio-msg-xen specific to Xen > > * Usable on any Xen system (including x86 where FF-A does not exist) > > * Using Xen events and page grants > > > > * virtio-msg over admin virtqueues > > * This allows any virtio-pci device that supports admin virtqueues to also > > support a virtio-msg bus that supports sub devices > > * [We are looking for collaborators for this work] > > > > Changes since RFC2: > > > > Spec Functional: > > * Made the common message header 8 bytes and added a token for optional use > > when parallel outstanding requests are possible > > * Made the 8 byte fields align to 8 byte offsets. > > This effects the {SET,GET}_VQUEUE messages > > * Many conformance cases have been tightened. > > > > Spec Editorial: > > * Major restructure to better align with virtio spec > > * Conformance model now matches other transports > > * Use C structures to define messages instead of tables > > * Added a section to describe how responses are matched to requests > > This includes the use of the new token field > > * Redefined / better described error handling between transport and bus > > layers to eliminate the need for the bus to generate fake response messages > > * Included editorial feedback from RFC2 > > > > Eco-system: > > * Added virtio-msg-loopback demo > > * Arm has published the first draft of the virtio-msg over FFA spec [6] > > * virtio-msg over FFA has been demonstrated with both Trusty and OP-TEE > > secure world > > * LKML RFC has been sent [7] > > * QEMU RFC has been sent [8] > > > > This is the first non-RFC patch series. The known short comings have been > > addressed. We ask for review in earnest on this series and thank you for > > any feedback you can provide. > > > > Background info and work in progress implementations: > > * HVAC project page with intro slides [1] > > * HVAC demo repo w/ instructions in README.md [2] > > * Kernel w/ virtio-msg common level and ffa support [3] > > * QEMU w/ support for one form of virtio-msg-amp [4] > > * Portable RTOS library w/ one form of virtio-msg-amp [5] > > > > In addition to the QEMU system based demos in the hvac-demo repo, we also have > > two hardware systems running: > > * AMD x86 + AMD Arm Versal connected via PCIe > > * ST STM32MP157 A7 Linux using virtio-i2c provided by M4 Zephyr > > > > Please note that although the demos work, a few have not been aligned > > with this version of the spec. > > > > [1] > > https://linaro.atlassian.net/wiki/spaces/HVAC/overview > > 05%7C02%7Cparav%40nvidia.com%7Cf7f430294c37485df25808de5cf88d95%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C6390 > > 50419790817373%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs > > IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=JnCO8QgAIiyGAprBLkprUd8A3162wCFpmGic3JKoHXo%3D&reserved=0 > > [2] https://github.com/wmamills/hvac- > > demo&data=05%7C02%7Cparav%40nvidia.com%7Cf7f430294c37485df25808de5cf88d95%7C43083d15727340c1b7db39efd9ccc17a%7C0%7 > > C0%7C639050419790868944%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIj > > oiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=XeBuS8Hr%2FDETKfSyidKKGoGq6OTUcOYoeSGDouUMcf4%3D&reserved=0 > > [3] > > https://git.kernel.org/pub/scm/linux/kernel/git/vireshk%252 > > Flinux.git%2Flog%2F%3Fh%3Dvirtio%2Fmsg&data=05%7C02%7Cparav%40nvidia.com%7Cf7f430294c37485df25808de5cf88d95%7C43083d1 > > 5727340c1b7db39efd9ccc17a%7C0%7C0%7C639050419790913867%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIw > > LjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=PuLq68Y0ZNCYbfrgDZlipfm44xHZp1%2F%2 > > BLu%2FaKQBBB%2Fo%3D&reserved=0 > > [4] https://github.com/edgarigl/qemu/commits/edgar/virtio- > > msg- > > rfc%2F&data=05%7C02%7Cparav%40nvidia.com%7Cf7f430294c37485df25808de5cf88d95%7C43083d15727340c1b7db39efd9ccc17a%7C0% > > 7C0%7C639050419790960971%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFO > > IjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=xyowKD9KG3IasQTiYCzfCRGqCLSF%2Fa1g4%2F2%2ByKb1OoA%3D&reserved=0 > > [5] https://github.com/arnopo/open-amp/commits/virtio- > > msg%2F&data=05%7C02%7Cparav%40nvidia.com%7Cf7f430294c37485df25808de5cf88d95%7C43083d15727340c1b7db39efd9ccc17a%7C0 > > %7C0%7C639050419791007707%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkF > > OIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=69OwO2wXi0%2FEhDDSR2uLG2iis5RYzI%2FLnlfkcRYao9o%3D&reserved=0 > > [6] https://documentation-/ > > service.arm.com%2Fstatic%2F68f647791134f773ab3f0a7c&data=05%7C02%7Cparav%40nvidia.com%7Cf7f430294c37485df25808de5cf88d9 > > 5%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C639050419791052848%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRy > > dWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=cD5VqKnTuIFqlN2XV3j%2FHQ > > Wvsz8UVe5PM0ZjMU3o0sM%3D&reserved=0 > > [7] > > https://lore.kernel.org/all/cover.1753865268.git.viresh.kumar@linar > > o.org%2F&data=05%7C02%7Cparav%40nvidia.com%7Cf7f430294c37485df25808de5cf88d95%7C43083d15727340c1b7db39efd9ccc17a%7C > > 0%7C0%7C639050419791093596%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsI > > kFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=NmhmL%2BuyVqnpHT5r9EfI2uzPf9LSXLga7bUw3FO5x4w%3D&reserved=0 > > [8] https://mail.gnu.org/archive/html/qemu-devel/2025- > > 10%2Fmsg07438.html&data=05%7C02%7Cparav%40nvidia.com%7Cf7f430294c37485df25808de5cf88d95%7C43083d15727340c1b7db39efd > > 9ccc17a%7C0%7C0%7C639050419791139232%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJ > > XaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=osI1FttOO9%2B01e%2B5EtwnYe%2Fl1%2BIvFjH%2Blyz2ipM3RM > > Q%3D&reserved=0 > > > > Bertrand Marquis (2): > > virtio-msg: add new command for bus normative > > virtio-msg: add conformance entries in conformance chapter > > > > Bill Mills (2): > > virtio-msg: Add virtio-msg, a message based virtio transport layer > > virtio-msg: link virtio-msg content > > > > commands.tex | 3 +- > > conformance.tex | 105 ++- > > content.tex | 1 + > > transport-msg.tex | 1640 +++++++++++++++++++++++++++++++++++++++++++++ > > 4 files changed, 1746 insertions(+), 3 deletions(-) > > create mode 100644 transport-msg.tex > > > > -- > > 2.34.1 > > >