- Virtio-msg - lists.linaro.org

by Bertrand Marquis

Hi Everyone, With a bit of delay here is the v2 of the linux PoC: https://github.com/bertrand-marquis/virtio-msg-spec/tree/linux-poc/v2/linux… There is now loopback and ffa bus implementation in it and the rework of the transport after removing config_get/set support from non sleepable context. I also did a bit or rework in the qemu patches to handle the comment and try to be less invasive in existing qemu code together with updating qemu virtio message implementation to be in sync with v2 oasis proposal. Any comment on this is still very welcome. For the arm_ffa patches, i will try to share them next week together with the xen branch going with it to be in a position to share a reproducible setup to do virtio between VMs. Cheers Bertrand 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.

1 week

2
2
0 0

[PATCH v1 0/6] virtio-msg transport layer

by Bill Mills

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. We are working on a few reusable bus implementations: * virtio-msg-ffa based on Arm's Virtio Message Bus over FF-A specification [6] 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 This series keeps 16-bit dev_num values per bus instance; deployments that need more than roughly 65k devices can scale by using multiple bus instances. Changes since v1 (virtio-msg-patch1): First, thank you for the detailed comments and broad interest on v1. This revision incorporates review feedback from Peter Hilber, Demi Marie Obenour, Parav Pandit, Andrei Homescu, Manos Pitsidianakis, Michael S. Tsirkin, Bill Mills, and HVAC group discussion. Highlights of the changes since v1: * Finalized the common transport message model: * keep the 8-byte common header * keep 16-bit device numbers per bus instance and a 16-bit msg_size field * note that deployments needing more than roughly 65k devices can scale by using multiple bus instances * clarify common message-ID encoding and validation boundaries * define request completion more precisely: a valid supported request completes with exactly one protocol response or a transport-visible failure * clarify request/response correlation and token handling, including the rule that devices echo the request token while the bus may rewrite tokens internally for correlation * preserve per driver/device request ordering while still allowing bus-correlated out-of-order responses and events * Clarified bus versus transport responsibilities and enumeration: * keep GET_DEVICE_INFO as a driver-issued transport message, and GET_DEVICES, PING, and EVENT_DEVICE as optional bus messages * require bus messages to use dev_num = 0 * bus implementations must expose only validated device numbers, may expose zero devices, and should delay device-number reuse to reduce races * EVENT_DEVICE is defined as a bus-originated ADDED/REMOVED hotplug event * tighten GET_DEVICES enumeration semantics, including empty-bitmap cases and guaranteed forward progress * Tightened initialization and feature negotiation: * use transport revision terminology consistently * keep GET_DEVICE_INFO as the only transport message used for early discovery * align the rest of initialization with the core virtio flow through reset, status progression, feature negotiation, FEATURES_OK verification, and DRIVER_OK * keep transport feature bits separate from device feature negotiation * define GET_DEVICE_FEATURES as reporting the feature blocks offered by the device * require GET_DEVICE_INFO to report enough feature blocks to cover all offered feature bits and bound max_virtqueues to 65536 * define SET_DRIVER_FEATURES as addressed-block updates carrying the subset chosen by the driver, which may be built up across multiple requests before FEATURES_OK * keep FEATURES_OK as the point where the device accepts or rejects the negotiated set * make GET_SHM mandatory for devices to implement while keeping driver use optional, and align the shared-memory identifier semantics with core virtio * Aligned configuration, status, and notification behavior with core virtio: * align GET_CONFIG, SET_CONFIG, EVENT_CONFIG, and device status handling more closely with the core virtio model * keep VIRTIO_MSG_F_STRICT_CONFIG_GENERATION only as optional strict-profile SET_CONFIG mismatch enforcement * define nonzero SET_CONFIG writes as all-or-nothing and rejected writes as length = 0 with no payload * limit EVENT_CONFIG status notifications to device-originated asynchronous status changes * make polling-only operation explicit, with EVENT_AVAIL and EVENT_USED used only when the endpoints choose event-driven notification * keep bus-side forwarding, polling, or synthesized notification delivery transparent to the transport-visible model * Refined virtqueue and reset semantics: * clarify queue-state transitions, SET_VQUEUE update behavior, and invalid reconfiguration cases * make SET_VQUEUE and RESET_VQUEUE reject cases deterministic no-op empty responses * define deterministic GET_VQUEUE zero-sentinel responses for unavailable, unimplemented, and out-of-range queues * define local admin virtqueue field semantics and the EVENT_AVAIL notification-data encoding more precisely * clarify reset-completion checks without duplicating the core virtio reset rules * Improved document quality: * reworked the chapter to better match existing virtio specification style * removed duplicated or ambiguous requirements * fixed label paths, direct field references, punctuation, and ambiguous wording * added informative known bus implementation examples * completed conformance coverage for driver, device, and bus clauses * normalized punctuation and wording for consistency with the rest of the spec Open topics and ongoing discussion: * Out-of-order/performance extensions: We kept the baseline behavior simple in this revision. If clear performance benefit is demonstrated, we are open to introducing an optional feature-bit based extension in a follow-up patch set. * Graceful device removal sequencing: Current direction is to handle graceful-remove sequencing in bus-specific specifications. We welcome feedback on whether any additional transport-level guidance would be useful. * Transport scope and mapping guidance: Discussion is still ongoing on transport-vs-bus binding scope, response status modeling, and mapping guidance for mmio/pci/vhost-user/KVM userspace cases. We are collecting reviewer input before deciding on follow-up text. * Potential virtio-msg over virtqueues for PCI/MMIO: This is still early discussion, including whether admin virtqueues should be used or extended for this purpose. There is no consensus yet, and we are continuing design exploration. Eco-system: * Added virtio-msg-loopback demo * Arm has published the Virtio Message Bus over FF-A specification [6] * virtio-msg over FF-A 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 v2 of the first non-RFC patch series. We are grateful for the review feedback and interest received on v1, and we ask for continued review on this revision. 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 [2] https://github.com/wmamills/hvac-demo [3] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/linux.git/log/?h=vi… [4] https://github.com/edgarigl/qemu/commits/edgar/virtio-msg-rfc/ [5] https://github.com/arnopo/open-amp/commits/virtio-msg/ [6] https://developer.arm.com/documentation/den0153/0101/ [7] https://lore.kernel.org/all/cover.1753865268.git.viresh.kumar@linaro.org/ [8] https://mail.gnu.org/archive/html/qemu-devel/2025-10/msg07438.html Bertrand Marquis (4): virtio-msg: add new command for bus normative virtio-msg: Add the FF-A bus bibliography reference virtio-msg: add conformance entries in conformance chapter virtio-msg: propose common-spec integration text 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 | 97 ++- content.tex | 18 +- introduction.tex | 6 +- transport-msg.tex | 2071 +++++++++++++++++++++++++++++++++++++++++++++ 5 files changed, 2185 insertions(+), 10 deletions(-) create mode 100644 transport-msg.tex -- 2.34.1

1 week, 4 days

2
9
0 0

Virtio message status update

by Viresh Kumar

Hello, The progress has been a bit slower since past few months (because of relocation to other stuff), but some progress was made (mostly around AMD's AMP stuff). - Rebased AMP Sapphire and generic PCI virtio-msg drivers (from Edgar/Bill) over latest virtio-msg repository and made few changes to make them work again. - Tested the generic PCI version with help of Edgar's QEMU based setup. I have received the physical board recently, will try to test with that next. - Made significant changes to both the drivers to bring them closer to how virtio-msg FFA and loopback drivers look. Also redesigned driver initialization and fixed how Ping implementation was working. - Eventually the code was much cleaner and much shorter. - The implementation was based on a simple predefined (fixed) single producer - single consumer queue. Bill/Edgar documented [1] a new shared memory layout earlier but was never implemented. Implemented the first version of that for both Linux and QEMU. -- viresh [1] https://github.com/wmamills/hvac-demo/blob/main/notes/amp-data-structures.h

2 weeks, 4 days

1
0
0 0

Linux Loopback POC

by Bertrand Marquis

Hi Everyone, I have a first PoC showing virtio-msg working with a loopback system between Linux kernel and Qemu. The patches, build and run instructions can be found here: https://github.com/bertrand-marquis/virtio-msg-spec/tree/linux-poc/v0/linux… This is very early stage but this shows a fully functional version with rng and block validated. I used ChatGPT help to fix issues and write part of the code (or big parts for Qemu) and this is far from upstreamable so do not share that. I will share a v1 in the next weeks with FF-A support but i still have some timings and DMA issues to solve. Any comment on this is more than welcome !! Cheers Bertrand 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.

1 month

3
11
0 0

PDF of Bertrand's latest work

by Bill Mills

All, Bertrand's PR#31 has been accepted to the virtio-msg-patch1 branch and the PDF of this is available at [1] and can also be found on the repo's front page. The format of the branch is all 76 commits on top of the original virtio-msg-patch1 branch. In the next week I will be squashing and rebasing this work to make a virtio-msg-patch2 branch. If you see anything that you that should be changed, please propose a new PR to virtio-msg-patch1 and I will fold any new commits into the patch2 branch later. Thanks, Bill [1] https://github.com/Linaro/virtio-msg-spec/releases/download/virtio-msg-patc… -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

1 month, 2 weeks

1
0
0 0

QEMU virtio-msg documentation

by Edgar E. Iglesias

Hi all, I've updated the QEMU virtio-msg branch, mainly by adding documentation for the virtio-msg-bus AMP PCI device. In the process of updating the documentation, I started to question the value of the multi-FIFO support in QEMU. It may just add confusion, and the Linux driver doesn't support it yet. So I chose to remove it and leave that for future work. Here's the branch and the relevant spec files: https://github.com/edgarigl/qemu/tree/edgar/virtio-msg-rfc virtio-msg-bus AMP PCI spec (temporary location): https://github.com/edgarigl/qemu/blob/edgar/virtio-msg-rfc/docs/system/devi… QEMU virtio-msg AMP PCI device usage: https://github.com/edgarigl/qemu/blob/edgar/virtio-msg-rfc/docs/system/devi… Let me know if you have any comments. Best regards, Edgar

1 month, 3 weeks

1
0
0 0

Sorry for recent spam; adjustments have been made

by Bill Mills

All, We have had a number of spam emails on this list in the past few weeks. I set all spam authors (ever) to discard and all new subscription requests to require moderation. Sorry for the noise. Bill -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

3 months

1
0
0 0

Who can help r e c o v e r stolen c r y p t o assets

by arlettepetee＠gmail.com

Some victims of c r y p t o i n v e s t m e n t s c a m s try professional tracing services like vaulttraces.com. These companies analyze blockchain data to track the movement of funds. Having complete documentation of your transactions can improve the chances of identifying where the assets went. For assistance reach out to them on their Website;: https://vaulttraces.com/contact.html . Mail-Box: info(a)vaulttraces.com . Or WhatsApp: +1 (570) 291-8211

3 months

1
0
0 0

Best c r y p t o c u r r e n c y r e c o v e r y companies

by arlettepetee＠gmail.com

If you’ve been affected by a c r y p t o s c a m, you could look into recovery services like vaulttraces . Their specialists work on tracing stolen digital assets through blockchain technology. It’s important to provide as much evidence as possible when reporting the case. reach out ;: vaulttraces com .

3 months

1
0
0 0

HOW TO HIRE A LEGITIMATE HACKER

by Peter Nguyen

If you find yourself in a similar situation—having lost significant amounts in Bitcoin or struggling with hacked social media accounts—don’t lose hope. Safe Guard Hacker is here to assist you every step of the way. Contact them today via WhatsApp at +44 7426 168300 and take the first step toward reclaiming what’s rightfully yours. Email: safeguardbitcoin(a)consultant.com Website: https://safeguardbitcoin.wixsite.com/safeguard-bitcoin--1

3 months

1
0
0 0

Legitimate Crypto Recovery Company You Can Trust To Recover Lost Bitcoin and Ethereum.

by raphaelleo894＠gmail.com

Dune Nectar Web Expert assists individuals and organisations in promptly and compassionately recovering misplaced or misappropriated funds. Our team comprises experienced specialists in financial recovery, fraud investigation, and client advocacy, with strong customer ratings on Google Reviews and Trustpilot. Each case is handled urgently, empathetically, and results-oriented. We address cryptocurrency scams, chargeback and payment-recovery disputes, forex and investment frauds, phishing and social-engineering schemes, and other misappropriations. For cryptocurrency matters, we combine blockchain tracing with investigative methods to map fund movements and identify parties. For chargebacks and payment disputes, we review merchant records, processor policies, and transaction timelines to build evidentiary support. For forex and investment fraud, we reconstruct transaction histories, verify counterparties’ regulatory status, and coordinate with compliance experts to seek restitution via legal and administrative channels. Our process is transparent and methodical: intake includes assessment of documents, transaction logs, and communications to determine feasibility and strategy; forensic examinations employ blockchain analytics, bank tracing, and digital forensics; targeted outreach is made to processors, exchanges, and institutions; and, when appropriate, we coordinate with law enforcement, regulators, and external counsel. Clients receive regular updates, defined timelines, and clear explanations of options and probable outcomes. We pursue proactive, pragmatic recovery strategies while openly communicating risks and impediments—jurisdictional limits, counterparty anonymity, and regulatory differences. To address these, we maintain a network of legal partners, compliance advisers, and international contacts to facilitate cross-border cooperation and remedies, including mutual legal assistance, exchange-freeze petitions, and civil recovery proceedings. Engaging Dune Nectar Web Expert provides a partner committed to integrity, transparency, and demonstrable results, with explicit engagement terms, documented action plans, periodic reports, and guidance on legal processes with projected timelines, costs, and expected outcomes. In summary, our objective is to recover clients’ assets through bespoke, transparent, and effective solutions combining forensic technology, regulatory expertise, and proven investigative workflows. To report a case, contact: Email: "Support (@) Dunenectaronlineexpert . Com" W/A: https://wa.link/3gfxoy

3 months, 1 week

1
0
0 0

Re: [Linaro/virtio-msg-spec] Review v1/v0 (PR #31)

by Bill Mills

Hi All, This email comes from the github PR but I am going to respond here. On 2/23/26 4:45 AM, bertrand-marquis wrote: > Hi Everyone, > > This pull request include a number of fixes or changes to handle the review > comment we got on virtio mailing list. > > Some points are not handled because they need a decision between us first > (following summary was generated by chatgpt): > > Ordering / Out‑of‑Order Feature Discussion > > * Parav Pandit proposes relaxing the strict request/response ordering > because it is too constraining for high‑performance data paths. He > suggests that the bus may need to deliver responses out of > order, and the spec should support that for performance. > * Demi Marie Obenour raises reset and out‑of‑order race risks if ordering > is relaxed. She suggests a generation/stream number or bus‑level reset > semantics to avoid stale or mis‑matched responses. > * Michael S. Tsirkin recommends keeping v1 simple and introducing > performance features via optional feature bits. This aligns with making > relaxed ordering a negotiated capability rather than a > baseline requirement. > I don't think transport level operations (excepting Virtqueue notifications ) have a big impact on performance. Demi seemed to understand our POV once she saw the option for events to go out of band. At least part of the time Parav was looking at virtio-msg NOT as a transport replacement (using existing virtqueue's in shared memory) and instead was looking at it as full virtio over a message channel (like virtio over tcp). Michael seemed to agree that was out of scope for our work and would need to be its own thing. However it is not clear if or when Parav has changed his thinking. > Configuration Generation Optional Feature Discussion > > * Peter Hilber suggests making the SET_CONFIG generation count optional > or dropping it, because Linux drivers assume config writes are not > rejected and do not retry. His rationale is avoiding > incompatibility with existing driver behavior. TL;DR include the generation counter in the message but eliminate the "rejection" of the SET_CONFIG and make it the devices job to coalesce the new value into the config space. virtio-msg has a race condition in config write that virtio-pci and virtio-mmio does not have due to its trap and emulate nature. In virtio-msg a write can race with a device side change to the same word(s). I agree with Peter that we should not expect the individual Linux drivers to respond to this. My initial thought was to do this in the driver side transport but Peter made we realize this is dumb. The transport will not have any extra info. It is better to push this race resolution back to the device. Giving the device the generation count allows the device to know if the driver was modifying the old value or the new value. I fully expect many device side implementations to ignore the generation count and just to take the new value but providing the generation count allows it to be more sophisticated if it wants to be. > > VQ Enabled Flag Discussion > > * Peter Hilber suggests adding an explicit “queue enabled” indication in > SET_VQUEUE (and also reporting it in GET_VQUEUE) so drivers can avoid > an extra GET_VQUEUE round‑trip just to confirm > enablement. This is aimed at reducing overhead in the initialization flow. > Ack > Device Number Size Discussion > > * Parav Pandit argues the 16‑bit device number is too small; he suggests > 32‑bit to cover >64k devices and PCI BDF domain usage. > * Demi Marie Obenour argues device identifiers should be 64‑bit or even > 128‑bit to ensure long‑term uniqueness. > * Peter Hilber highlights that reuse of device numbers after removal can > cause races, and suggests adding a reuse‑limiting policy. He ties this > to the broader question of expanding the device number > space. > 32 or 64 is fine. 128 seems overkill yes? One PCI bus has a limit of 2^64 devices. > EVENT_CONFIG Data Mandatory Discussion > > * Demi Marie Obenour proposes making EVENT_CONFIG always include > configuration data (MUST), to avoid a round trip. If data is mandatory, > she notes that offset/length‑only signaling becomes > unnecessary. NAK. This will prevent simple out of band notification for the EVENT_AVAIL. Demi seemed to want OOB notifications so this seems in contradiction. > * There is a noted contradiction with earlier guidance (Peter Hilber) and > the current spec change ( I already updated the spec to require offset/ > length even when data is omitted, Even this will prevent OOB. The existing mechanisum allow this to be negociated. Any bus that uses OOB can NAK these feature bits to prevent use. > keeping data optional as I think this > makes sense and i am not quite sure we can mandate the data without > breaking compatibility with other transports or existing devices). This > needs a clear decision. > > --------------------------------------------------------------------------- > > > You can view, comment on, or merge this pull request online at: > > https://github.com/Linaro/virtio-msg-spec/pull/31 <https://github.com/ > Linaro/virtio-msg-spec/pull/31> > > > Commit Summary > > * 52ffe64 <https://github.com/Linaro/virtio-msg-spec/pull/31/ > commits/52ffe641810d26860fbdbb45e7437c8df9360f6a> virtio-msg: clarify > device number vs device ID (Peter Hilber) > * 3a70c3a <https://github.com/Linaro/virtio-msg-spec/pull/31/ > commits/3a70c3ad6a277cf08931a4efb86b3a41fd29eb7b> virtio-msg: fix minor > grammar in device topology (Peter Hilber) > * d677fc8 <https://github.com/Linaro/virtio-msg-spec/pull/31/commits/ > d677fc8c1717320416460d911143fa243b8f4eb8> virtio-msg: use “transport > revision” consistently (Peter Hilber) > * c0020f1 <https://github.com/Linaro/virtio-msg-spec/pull/31/commits/ > c0020f12b985b25c66e3afcf348c1b7aaa81fb78> virtio-msg: use active voice > for reserved header bits (Peter Hilber) > * 7eafee2 <https://github.com/Linaro/virtio-msg-spec/pull/31/ > commits/7eafee2d67d847862f6ff7a9a2899fb5b081b217> virtio-msg: drop > duplicate GET_DEVICE_INFO requirement (Peter Hilber) > * 623334c <https://github.com/Linaro/virtio-msg-spec/pull/31/ > commits/623334cf0ae1c2289d23c3b47bdd7f2cfa801ed7> virtio-msg: clarify > removal handling (Peter Hilber) > * 4c75e07 <https://github.com/Linaro/virtio-msg-spec/pull/31/ > commits/4c75e07c29f4aa2dbdccfcde8c89d7d9953f28f6> virtio-msg: allow > zero devices per bus instance (Peter Hilber) > * 2bbad99 <https://github.com/Linaro/virtio-msg-spec/pull/31/ > commits/2bbad994805f216755ba6abfe3a1b844e41f30aa> virtio-msg: add note > on config vs virtqueue data (Demi Marie Obenour) > * 094111b <https://github.com/Linaro/virtio-msg-spec/pull/31/ > commits/094111b9d9e019c9cc4e50d31bf1c27ea5c8d3dc> virtio-msg: rename > READY to ADDED in bus device events (Parav Pandit) > * 1e1e817 <https://github.com/Linaro/virtio-msg-spec/pull/31/ > commits/1e1e81778404d596f1216385a8c8945cf6dbdbdc> virtio-msg: clarify > transport feature negotiation (Peter Hilber) > * f50fe3c <https://github.com/Linaro/virtio-msg-spec/pull/31/commits/ > f50fe3c985bd6061449f7ab50b45a045bbe15aa7> virtio-msg: clarify > generation count reset semantics (Peter Hilber) > * f462169 <https://github.com/Linaro/virtio-msg-spec/pull/31/commits/ > f462169090b0907b59b14ed0b6ee952c67934df1> virtio-msg: clarify > notification wording (Peter Hilber) > * 2d8c995 <https://github.com/Linaro/virtio-msg-spec/pull/31/ > commits/2d8c9952035cf72331de5b22ea13aacd9b2c5a29> virtio-msg: require > EVENT_USED unless polling (Peter Hilber) > * 4b8c483 <https://github.com/Linaro/virtio-msg-spec/pull/31/ > commits/4b8c483c79709a509a5961309435a941a8e17110> virtio-msg: drop > RESET_VQUEUE-before-reprogramming (Peter Hilber) > * b783fc5 <https://github.com/Linaro/virtio-msg-spec/pull/31/commits/ > b783fc534d8973167770515d12a5fd22703ba331> virtio-msg: align admin vq > field widths (Peter Hilber) > * 818142e <https://github.com/Linaro/virtio-msg-spec/pull/31/ > commits/818142ed4c8612645a46ed211a0a172267684d35> virtio-msg: proposal: > clarify echoed fields (Peter Hilber) > * 6ba8c70 <https://github.com/Linaro/virtio-msg-spec/pull/31/ > commits/6ba8c708335f9068c0045f74714f9258b8faf488> virtio-msg: require > clearing FEATURES_OK (Peter Hilber) > * 21aeb49 <https://github.com/Linaro/virtio-msg-spec/pull/31/ > commits/21aeb4982be32a80ea2a4852cef9dae8f552786d> virtio-msg: widen > GET_SHM fields (Peter Hilber) > * 3e007fd <https://github.com/Linaro/virtio-msg-spec/pull/31/ > commits/3e007fdbc75eadb931c2cb4eaf4954255f51e419> virtio-msg: clarify > EVENT_CONFIG ranges (Peter Hilber) > * f109559 <https://github.com/Linaro/virtio-msg-spec/pull/31/commits/ > f1095590057baff76976d371a1ecd95357ca3f35> virtio-msg: streamline > DEVICE_NEEDS_RESET text (Peter Hilber) > * 835ef71 <https://github.com/Linaro/virtio-msg-spec/pull/31/ > commits/835ef718e432d7b8df08cf0e25f59f89a0a0bdc6> virtio-msg: scope > msg_id validation (Peter Hilber) > * 07b0d08 <https://github.com/Linaro/virtio-msg-spec/pull/31/ > commits/07b0d08d12c9038d59f07a627dbf408ec7424435> virtio-msg: drop > FEATURES_OK sentence (Peter Hilber) > * ba844e9 <https://github.com/Linaro/virtio-msg-spec/pull/31/commits/ > ba844e93dd1a685fae0d0c04eb216784962a91e1> virtio-msg: note bus-level > errors (Demi Marie Obenour) > * 3c685b6 <https://github.com/Linaro/virtio-msg-spec/pull/31/ > commits/3c685b6d5facca7ff01cce29869893c077153209> virtio-msg: reframe > ordering responses (Demi Marie Obenour) > * 8a529c0 <https://github.com/Linaro/virtio-msg-spec/pull/31/ > commits/8a529c0a6bd261ef0bdda92b1715bfb5e5e8e034> virtio-msg: clarify > virtqueue data path (Demi Marie Obenour) > * 0df8574 <https://github.com/Linaro/virtio-msg-spec/pull/31/ > commits/0df8574759c0685e802a99c34ef09e0d7cef3af2> virtio-msg: allow > out-of-order events (Demi Marie Obenour) > * 773970f <https://github.com/Linaro/virtio-msg-spec/pull/31/ > commits/773970f939facdba7ba7f2ff70838d0133e6cd58> virtio-msg: use > physical address terminology (Demi Marie Obenour) > > > File Changes > > (1 file <https://github.com/Linaro/virtio-msg-spec/pull/31/files>) > > * *M* transport-msg.tex <https://github.com/Linaro/virtio-msg-spec/ > pull/31/files#diff- > ae43224efc56fefe20a4d5de6f7cfb5ccd94950be1246b6ece5274c6c994e167> (232) > > > Patch Links: > > * https://github.com/Linaro/virtio-msg-spec/pull/31.patch <https:// > github.com/Linaro/virtio-msg-spec/pull/31.patch> > * https://github.com/Linaro/virtio-msg-spec/pull/31.diff <https:// > github.com/Linaro/virtio-msg-spec/pull/31.diff> > > — > Reply to this email directly, view it on GitHub <https://github.com/Linaro/ > virtio-msg-spec/pull/31>, or unsubscribe <https://github.com/notifications/ > unsubscribe-auth/ > AIBXWC5SZFXJ2MVGMCE7AYL4NLD5PAVCNFSM6AAAAACV4PIWDWVHI2DSMVQWIX3LMV43ASLTON2WKOZTHE3TOMRUG42TEMI>. > You are receiving this because your review was requested.Message ID: > <Linaro/virtio-msg-spec/pull/31(a)github.com> >

3 months, 1 week

2
1
0 0

Virtio Specification comment handling

by Bertrand Marquis

Hi Everyone, I pushed a first pull request to try to handle some of the comments we got on virtio mailing list: https://github.com/Linaro/virtio-msg-spec/pull/31 In my comment i list some of the points for which we will need to have a discussion on thursday to decide how and if we handle them. Please check and add any comments you might have. Cheers Bertrand 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.

3 months, 2 weeks

1
0
0 0

Hire SAFEGUARD RECOVERY, a Bitcoin recovery specialist, to retrieve stolen or lost coins.

by sophia fourest

Hire SAFEGUARD RECOVERY, a Bitcoin recovery specialist, to retrieve stolen or lost coins. I invested $320,000 in Tether (USDT) on a fraudulent website after falling for a romantic scam. I felt completely helpless and in need of assistance after realizing I had been duped. I started looking for a hacker online and found SAFEGUARD RECOVERY. I had optimism because of his professionalism and knowledge. I'm happy to report that SAFEGUARD RECOVERY successfully recovered my stolen money after working relentlessly to do so! I am immensely appreciative of their help and heartily urge anyone in a comparable circumstance to use their services. I'm grateful Email: safeguardbitcoin(a)consultant.com WhatsApp: +44 7426 168300 Website: https://safeguardbitcoin.wixsite.com/safeguard-bitcoin--1

4 months, 1 week

1
0
0 0

Share vs Lend - Vsock memory sharing over virtio-msg-ffa

by Viresh Kumar

Hello, I am trying to get feedback / ideas (specially from the people in --to) before I reach out to LKML. Problem statement: Share memory (dma-buf/dma-heap fd) over VSock (over virtio-msg-ffa). Current status: I have implemented the first version [1]/[2]. The system-heap memory is successfully shared with OPTEE, test setup available here [3]. Workflow: Userspace: open("/dev/dma_heap/system", O_RDWR) + ioctl(heap_fd, DMA_HEAP_IOCTL_ALLOC, &alloc) + sendmsg(sock, &msg, 0) // msg: SCM_VSOCK_SHMEM / VSOCK_SHMEM_TYPE_FFA / VSOCK_SHMEM_SUBOP_OFFER Kernel: vsock_sendmsg_shmem(vsk, msg) | vsk->transport->map_dma_buf(dmabuf) | virtio_transport_map_dma_buf(dmabuf) | dma_buf_attach(dmabuf, dev); // Vsock's underlying device - virtio-msg device + dma_buf_map_attachment_unlocked(dbuf->attach, DMA_BIDIRECTIONAL); | system_heap_map_dma_buf(attach, dir); | dma_map_sgtable(attachment->dev, table, dir, attrs=0); | virtio_msg_dma_map_sg_dev(dev, sgl, nents, dir, attrs); // FFA dma-ops | ffa_dev->ops->mem_ops->memory_share(&args); + vmfdev->send(vmfdev, request, response, &vmfdev->idata); The memory is shared with FFA SHARE type. This doesn't require a custom heap and works with any DMA heap/buf, system heap is just an example here. FFA supports LEND-ing the memory as well and Google needs it. And this is where I am _blocked_ right now and need help. We need to support both SHARE (both sides can access memory) and LEND (Linux doesn't access it any further - unmapped) mechanisms and I am not sure how to move forward. - We can pass the share-type from userspace and that can reach up to vsock / dma-buf (with minor API change to dma_buf_map_attachment_unlocked()) / system-heap. - But after that the standard dma_map_sgtable() call takes only one configurable parameter, `attributes` (which is set to 0 for now by system heap). There is nothing else which I can use to pass the flag to FFA specific DMA OPs. - I thought maybe I can create a new DMA attribute: `DMA_ATTR_MEM_LEND`, which can be passed in the `attr` field and that will work I guess. - But I am not sure if it would be acceptable upstream to add a new attribute for this. - And so I am looking for some ideas. -- viresh [1] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/linux.git/log/?h=vi… [2] Patches of interest - vsock: Add shared-memory support for virtio and loopback - virtio-msg: ffa: Add device DMA-OPS [3] https://linaro.atlassian.net/wiki/spaces/HVAC/pages/30372528129

4 months, 1 week

5
14
0 0

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

by Bill Mills

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. How much of the bus level should be described in the virtio spec is one item we wish to discuss. This draft takes a middle approach by describing the bus level and defining some standard bus level messages that MAY be used by the bus. It also describes a range of bus messages that are implementation dependent. 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. 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 [2] https://github.com/wmamills/hvac-demo [3] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/linux.git/log/?h=vi… [4] https://github.com/edgarigl/qemu/commits/edgar/virtio-msg-rfc/ [5] https://github.com/arnopo/open-amp/commits/virtio-msg/ [6] https://documentation-service.arm.com/static/68f647791134f773ab3f0a7c [7] https://lore.kernel.org/all/cover.1753865268.git.viresh.kumar@linaro.org/ [8] https://mail.gnu.org/archive/html/qemu-devel/2025-10/msg07438.html 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

4 months, 2 weeks

2
7
0 0

[PATCH v1 0/8] virtio-msg transport layer

by Bill Mills

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. How much of the bus level should be described in the virtio spec is one item we wish to discuss. This draft takes a middle approach by describing the bus level and defining some standard bus level messages that MAY be used by the bus. It also describes a range of bus messages that are implementation dependent. 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. 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 [2] https://github.com/wmamills/hvac-demo [3] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/linux.git/log/?h=vi… [4] https://github.com/edgarigl/qemu/commits/edgar/virtio-msg-rfc/ [5] https://github.com/arnopo/open-amp/commits/virtio-msg/ [6] https://documentation-service.arm.com/static/68f647791134f773ab3f0a7c [7] https://lore.kernel.org/all/cover.1753865268.git.viresh.kumar@linaro.org/ [8] https://mail.gnu.org/archive/html/qemu-devel/2025-10/msg07438.html Alex Bennée (1): local: add local build help and github automation (!UPSTREAM) Bertrand Marquis (2): virtio-msg: add new command for bus normative virtio-msg: add conformance entries in conformance chapter Bill Mills (5): email: Add script and cover letter for RFC1 email: adjust cover letter for RFC2 email: adjust cover letter for RFC3 virtio-msg: Add virtio-msg, a message based virtio transport layer virtio-msg: link virtio-msg content .github/PULL_REQUEST_TEMPLATE.md | 14 +- .github/workflows/deploy.yaml | 38 + .github/workflows/test.yml | 15 + .prjinfo/sendmail/cover.txt | 125 +++ .prjinfo/sendmail/send.sh | 57 ++ Makefile | 33 + REVISION | 2 +- commands.tex | 3 +- conformance.tex | 105 +- content.tex | 1 + make-setup-generated.sh | 31 +- makeall.sh | 4 +- makehtml.sh | 2 +- makepdf.sh | 2 +- transport-msg.tex | 1640 ++++++++++++++++++++++++++++++ 15 files changed, 2052 insertions(+), 20 deletions(-) create mode 100644 .github/workflows/deploy.yaml create mode 100644 .github/workflows/test.yml create mode 100644 .prjinfo/sendmail/cover.txt create mode 100755 .prjinfo/sendmail/send.sh create mode 100644 Makefile create mode 100644 transport-msg.tex -- 2.34.1

4 months, 2 weeks

1
9
0 0

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

by Bill Mills

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. How much of the bus level should be described in the virtio spec is one item we wish to discuss. This draft takes a middle approach by describing the bus level and defining some standard bus level messages that MAY be used by the bus. It also describes a range of bus messages that are implementation dependent. 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. 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 Spec Editorial: * Major restructure to better align with virtio spec * Conformance model now matches * 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: * Add virtio-msg-loopback demo * Arm has published the first draft of the virtio-msg over FFA spec * virtio-msg over FFA has been demonstrated with both Trusty and OP-TEE secure world * QEMU RFCv1 has been sent * LKML RFCs have been sent 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, not all of them have been aligned with this version of the spec. [1] https://linaro.atlassian.net/wiki/spaces/HVAC/overview [2] https://github.com/wmamills/hvac-demo [3] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/linux.git/log/?h=vi… [4] https://github.com/edgarigl/qemu/commits/edgar/virtio-msg-new [5] https://github.com/arnopo/open-amp/commits/virtio-msg/ 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

4 months, 3 weeks

1
4
0 0

[RFC] Vsock: Which device should we use for mapping memory ?

by Viresh Kumar

Happy new year everyone, I have a few questions regarding the design of the whole memory sharing over Vsock work and looking to get some feedback before I spend time making the changes. The initial design (from Nov): - Initially I implemented a FFA based DMA heap (no DMA ops used), which would allocate memory and make direct FFA calls to send the memory to the other endpoint. - The userspace would open this heap, allocated dma-buf and pass its FD over Vsock. - The Vsock layer would then call ->shmem() (a new callback I added to dma-buf/heap, which will send memory over FFA and return ffa bus address), to get the metadata to be shared over Vsock. The current design: - In one of the calls Bertrand suggested to not create parallel paths for sending memory over FFA. Instead we should use the exiting dma-ops for FFA (used for virtqueue and reserved-mem) somehow. - I created a platform device (as a child of the FFA device) and assigned a new set of DMA ops to it (the only difference from reserved-mem ops is that we don't do swiotlb here and allocate fresh instead of the reserved mem). - This pdev is used by the DMA heap to allocate memory using dma_alloc_coherent() and that made sure everything got mapped correctly. - I still need a dma-buf helper to get the metadata to send over Vsock. The existing helper was renamed as s/shmem/shmem_data. The future design (that I have questions about): - The FFA specific DMA heap I now have doesn't do anything special compared to the system heap, mostly exactly same. - Which made me realize that probably I shouldn't add a new heap (Google can add one later if they really want) and the solution should work with any heap / dma-buf. - So, userspace should allocate heap from system-heap, get a dma-buf from it and send its FD. - The vsock layer then should attach this dma-buf to a `struct device` somehow and then call map_dma_buf() for the dma-buf. This requires the dma-ops of the device to be set to the FFA based dma-ops and then it should just work. - The tricky point is finding that device struct (as Vsock can't get it from dma-buf or usersapce). - One way, I think (still needs exploring but should be possible) is to use the struct device of the virtio-msg device over which Vsock is implemented. We can set the dma-ops of the virtio-msg device accordingly. - The system heap doesn't guarantee contiguous allocation though (which my FFA heap did) and so we will be required to send a scatter-gather list over vsock, instead of just one address and size (what I am doing right now). - Does this make sense ? Or if there is a use-case that this won't solve, etc ? -- viresh

5 months

2
4
0 0

Address space definition with virtio-msg and Xen grants ?

by Teddy Astie

Hello, I have some questions / feedback on the Xen side of virtio-msg. AFAIU virtio-msg defines a protocol in order to deal with discovery (optional) and configuration of the PV devices. But things are undefined regarding what is a "memory address". In Xen memory model with grants, each guest has its own memory space. The frontend shares memory pages with the backend through grants pages identified by grant references. So in a design based on grants, virtio addresses can't (or at least shouldn't) be guest physical address; but needs to be something derived on grants. A earlier design [1] was forging a address with the grant reference, but I feel it's not great, as it forces "map+unmap" cycles for temporary buffers thus has the same performance problem as Xen PV drivers (without persistent grants) where map+unmap cycles is a performance problem. And would make the address space very fragmented and in often limited to 4KB buffers. One idea that is already used by Xen displif (PV Display) is to have a "gref directory" and describe the address space on that. The gref directory is roughly a array of grant references (shared pages infos) that could describe a address space starting at 0, where each page is defined by a grant reference of the directory. That way, the backend can freely keep all or a part or the address space persistently mapped (or eventually map it all at once); and the address space is also contiguous which would help with >4KB buffers. Any thoughts ? [1] https://static.sched.com/hosted_files/xen2021/bf/Thursday_2021-Xen-Summit-v… -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech

5 months

2
4
0 0

Meeting Notes from Dec 18

by Bill Mills

All, I have updated the December wiki page with the notes from today. Any fixes are appreciated. https://linaro.atlassian.net/wiki/spaces/HVAC/pages/30510383105/2025-12+Upd… The page has a link and password to the recording and transcript if you want to see or hear the whole thing. Thanks, Bill -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

5 months, 3 weeks

1
0
0 0

[PATCH] dma-buf: add no-op stubs when CONFIG_DMA_SHARED_BUFFER is disabled

by Viresh Kumar

Move several dma-buf function declarations under CONFIG_DMA_SHARED_BUFFER and provide static inline no-op implementations for the disabled case to allow the callers to build when the feature is not compiled in. Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> --- include/linux/dma-buf.h | 116 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 116 insertions(+) diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h index d58e329ac0e7..06e494d8f6b0 100644 --- a/include/linux/dma-buf.h +++ b/include/linux/dma-buf.h @@ -568,6 +568,7 @@ static inline bool dma_buf_is_dynamic(struct dma_buf *dmabuf) return !!dmabuf->ops->pin; } +#ifdef CONFIG_DMA_SHARED_BUFFER struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf, struct device *dev); struct dma_buf_attachment * @@ -609,4 +610,119 @@ int dma_buf_vmap_unlocked(struct dma_buf *dmabuf, struct iosys_map *map); void dma_buf_vunmap_unlocked(struct dma_buf *dmabuf, struct iosys_map *map); struct dma_buf *dma_buf_iter_begin(void); struct dma_buf *dma_buf_iter_next(struct dma_buf *dmbuf); + +#else +static inline struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf, + struct device *dev) +{ + return NULL; +} + +static inline struct dma_buf_attachment * +dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev, + const struct dma_buf_attach_ops *importer_ops, + void *importer_priv) +{ + return NULL; +} + +static inline void dma_buf_detach(struct dma_buf *dmabuf, + struct dma_buf_attachment *attach) { } + +static inline int dma_buf_pin(struct dma_buf_attachment *attach) +{ + return -EOPNOTSUPP; +} + +static inline void dma_buf_unpin(struct dma_buf_attachment *attach) { } + +static inline struct dma_buf * +dma_buf_export(const struct dma_buf_export_info *exp_info) +{ + return NULL; +} + + +static inline int dma_buf_fd(struct dma_buf *dmabuf, int flags) +{ + return -EOPNOTSUPP; +} + + +static inline struct dma_buf *dma_buf_get(int fd) +{ + return NULL; +} + +static inline void dma_buf_put(struct dma_buf *dmabuf) { } + +static inline struct sg_table * +dma_buf_map_attachment(struct dma_buf_attachment *, enum dma_data_direction) +{ + return NULL; +} + +static inline void dma_buf_unmap_attachment(struct dma_buf_attachment *, + struct sg_table *, + enum dma_data_direction) { } + +static inline void dma_buf_move_notify(struct dma_buf *dma_buf) { } + +static inline int dma_buf_begin_cpu_access(struct dma_buf *dma_buf, + enum dma_data_direction dir) +{ + return -EOPNOTSUPP; +} + +static inline int dma_buf_end_cpu_access(struct dma_buf *dma_buf, + enum dma_data_direction dir) +{ + return -EOPNOTSUPP; +} + +static inline struct sg_table * +dma_buf_map_attachment_unlocked(struct dma_buf_attachment *attach, + enum dma_data_direction direction) +{ + return NULL; +} + +static inline void +dma_buf_unmap_attachment_unlocked(struct dma_buf_attachment *attach, + struct sg_table *sg_table, + enum dma_data_direction direction) { } + +static inline int dma_buf_mmap(struct dma_buf *, struct vm_area_struct *, + unsigned long) +{ + return -EOPNOTSUPP; +} + +static inline int dma_buf_vmap(struct dma_buf *dmabuf, struct iosys_map *map) +{ + return -EOPNOTSUPP; +} + +static inline void dma_buf_vunmap(struct dma_buf *dmabuf, struct iosys_map *map) +{ } + +static inline int dma_buf_vmap_unlocked(struct dma_buf *dmabuf, + struct iosys_map *map) +{ + return -EOPNOTSUPP; +} + +static inline void dma_buf_vunmap_unlocked(struct dma_buf *dmabuf, + struct iosys_map *map) { } + +static inline struct dma_buf *dma_buf_iter_begin(void) +{ + return NULL; +} + +static inline struct dma_buf *dma_buf_iter_next(struct dma_buf *dmbuf) +{ + return NULL; +} +#endif /* CONFIG_DMA_SHARED_BUFFER */ #endif /* __DMA_BUF_H__ */ -- 2.31.1.272.g89b43f80a514

6 months, 1 week

1
0
0 0

PoC: Memory sharing: vsock + virtio-msg + FF-A + dma-heap

by Viresh Kumar

Hello, I was able to successfully test memory sharing over Vsock, implemented over a virtio message FFA transport. The memory is shared, as an FD, from Linux userspace (via a FFA specific DMA HEAP) and is received in OP-TEE as a buffer, which prints the string written by Linux. Steps to reproduce: - Jens shared an OP-TEE based setup few days back [1]. Reproduce it first. - Migrate to my branches for the following repositories within that: - build, optee_os, optee_test - Path to my repos: git@github.com:vireshk/ - branch: vsock/shmem - Migrate to my linux repo: git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/linux.git virtio/msg - Repeat the same test from Jens's setup: "xtest 2005" - The firmware side will print: Hello from shared memory via FD! This string was written by the Linux userspace in the memory provided by FFA DMA HEAP. Thanks. -- viresh [1] https://linaro.atlassian.net/browse/LEDGE-725

7 months, 1 week

2
1
0 0

Virtio Message Bus over FF-A 1.0 ALP0 released

by Bertrand Marquis

Hi Everyone, Today, Arm is releasing the first public version of the Virtio Message Bus over FF-A in version 1.0 and in quality state Alpha 0. The document is available for download here: https://developer.arm.com/documentation/den0153/0100 Please contact me if you have any comment, remarks, questions or improvements to suggest so that i can handle them before the spec reaches Beta quality. Regards Bertrand 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.

7 months, 1 week

2
1
0 0

[PATCH v2 0/4] virtio: Add the virtio-msg transport

by Edgar E. Iglesias

Hi all, This the RFC I'm preparing to send to upstream QEMU for initial RFC review. I didn't see much precedence for Signed-off-by lines in cover letter so instead I'm thinking to explicitely CC Bill and Alex and anyone else who would like to be on copy, just let me know. Changes from v1: * Move VIRTIO_MSG_VENDOR_ID to virtio-msg.c * Update to match recent spec changes (token + set/get_vqueue padding) * Add endian conversion of dev_num and msg_size * Add instructions for running on GPEX PCI x86 microVM and ARM virt * Add missing spsc_queue.h ------------------- This adds virtio-msg, a new virtio transport. Virtio-msg works by exchanging messages over a bus and doesn't rely on trapping and emulating making it a good fit for a number of applications such as AMP, real-time and safety applications. Together with the new transport, this series adds a PCI device that implements an AMP setup much like it would look if two SoC's would use virtio-msg across a PCI link. Current limitations: We only support a single device per bus (dev_num = 0). Shared memory queue layout likely to change in the future. Temporarily uses PCI Vendor Xilinx / Device 0x9039. Missing documentation. The virtio-msg spec: https://github.com/Linaro/virtio-msg-spec/ QEMU with these patches: https://github.com/edgarigl/qemu/tree/edgar/virtio-msg-rfc Linux with virtio-msg suppport: https://github.com/edgarigl/linux/tree/edgari/virtio-msg-6.17 To try it, first build Linux with the following enabled: CONFIG_VIRTIO_MSG=y CONFIG_VIRTIO_MSG_AMP=y CONFIG_VIRTIO_MSG_AMP_PCI=y Boot linux in QEMU with a virtio-msg-amp-pci device, in this example with a virtio-net device attached to it: x86/q35 machine: -device virtio-msg-amp-pci -device virtio-net-device,netdev=n1,bus=/q35-pcihost/pcie.0/virtio-msg-amp-pci/vmsg.0 -netdev user,id=n1 x86/microvm or ARM virt machines: -device virtio-msg-amp-pci -device virtio-net-device,netdev=n1,bus=/gpex-pcihost/pcie.0/virtio-msg-amp-pci/vmsg.0/virtio-msg/virtio-msg-proxy-bus.0 -netdev user,id=n1 Cheers, Edgar Edgar E. Iglesias (4): virtio: Introduce notify_queue virtio: Add virtio_queue_get_rings virtio: Add the virtio-msg transport virtio-msg-bus: amp-pci: Add generic AMP PCI device hw/misc/Kconfig | 7 + hw/misc/meson.build | 1 + hw/misc/virtio-msg-amp-pci.c | 324 ++++++++++++ hw/virtio/Kconfig | 4 + hw/virtio/meson.build | 5 + hw/virtio/virtio-msg-bus.c | 89 ++++ hw/virtio/virtio-msg.c | 598 ++++++++++++++++++++++ hw/virtio/virtio.c | 23 + include/hw/virtio/spsc_queue.h | 213 ++++++++ include/hw/virtio/virtio-bus.h | 1 + include/hw/virtio/virtio-msg-bus.h | 95 ++++ include/hw/virtio/virtio-msg-prot.h | 749 ++++++++++++++++++++++++++++ include/hw/virtio/virtio-msg.h | 45 ++ include/hw/virtio/virtio.h | 2 + 14 files changed, 2156 insertions(+) create mode 100644 hw/misc/virtio-msg-amp-pci.c create mode 100644 hw/virtio/virtio-msg-bus.c create mode 100644 hw/virtio/virtio-msg.c create mode 100644 include/hw/virtio/spsc_queue.h create mode 100644 include/hw/virtio/virtio-msg-bus.h create mode 100644 include/hw/virtio/virtio-msg-prot.h create mode 100644 include/hw/virtio/virtio-msg.h -- 2.43.0

7 months, 2 weeks

3
6
0 0

[PATCH v1 0/4] virtio: Add the virtio-msg transport

by Edgar E. Iglesias

Hi all, This the RFC I'm preparing to send to upstream QEMU for initial RFC review. A couple of limitations: I've not updated the protocol with the new msg_token field yet. We only support a single device per bus (dev_num = 0). The kernel driver only works as a module, when building it into the kernel it panics. ------------------- This adds virtio-msg, a new virtio transport. Virtio-msg works by exchanging messages over a bus and doesn't rely on trapping and emulating making it a good fit for a number of applications such as AMP, real-time and safety applications. Together with the new transport, this series adds a PCI device that implements an AMP setup much like it would look if two SoC's would use virtio-msg across a PCI link. The virtio-msg spec: https://github.com/Linaro/virtio-msg-spec/ Linux with virtio-msg: https://github.com/edgarigl/linux/tree/edgari/virtio-msg-6.17 To try it, first build Linux with the following as modules: CONFIG_VIRTIO_MSG=m CONFIG_VIRTIO_MSG_AMP=m CONFIG_VIRTIO_MSG_AMP_PCI=m Boot linux in QEMU with a virtio-msg-amp-pci device, in this example with a virtio-net device attached to it (x86/q35 machine): -device virtio-msg-amp-pci -device virtio-net-device,netdev=n1,bus=/q35-pcihost/pcie.0/virtio-msg-amp-pci/vmsg.0 -netdev user,id=nc Modprobe: modprobe virtio_msg_transport.ko modprobe virtio_msg_amp.ko modprobe virtio_msg_amp_pci.ko You now should see the virtio device. Cheers, Edgar Edgar E. Iglesias (4): virtio: Introduce notify_queue virtio: Add virtio_queue_get_rings virtio: Add the virtio-msg transport virtio-msg-bus: amp-pci: Add generic AMP PCI device hw/misc/Kconfig | 7 + hw/misc/meson.build | 1 + hw/misc/virtio-msg-amp-pci.c | 324 ++++++++++++ hw/virtio/Kconfig | 4 + hw/virtio/meson.build | 5 + hw/virtio/virtio-msg-bus.c | 89 ++++ hw/virtio/virtio-msg.c | 596 ++++++++++++++++++++++ hw/virtio/virtio.c | 23 + include/hw/virtio/virtio-bus.h | 1 + include/hw/virtio/virtio-msg-bus.h | 95 ++++ include/hw/virtio/virtio-msg-prot.h | 747 ++++++++++++++++++++++++++++ include/hw/virtio/virtio-msg.h | 45 ++ include/hw/virtio/virtio.h | 2 + 13 files changed, 1939 insertions(+) create mode 100644 hw/misc/virtio-msg-amp-pci.c create mode 100644 hw/virtio/virtio-msg-bus.c create mode 100644 hw/virtio/virtio-msg.c create mode 100644 include/hw/virtio/virtio-msg-bus.h create mode 100644 include/hw/virtio/virtio-msg-prot.h create mode 100644 include/hw/virtio/virtio-msg.h -- 2.43.0

7 months, 2 weeks

2
8
0 0

Notes and updated PR from Oct 23 meeting

by Bill Mills

All, The notes from today's meeting are on the wiki page: https://linaro.atlassian.net/wiki/spaces/HVAC/pages/30311874561/2025-10+Upd… PR #25 has been updated as discussed today and the PR header comment updated with changes. https://github.com/Linaro/virtio-msg-spec/pull/25 Thanks, Bill -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

7 months, 2 weeks

1
0
0 0

Notes and fixed up PR from meeting on 2025/10/16

by Bill Mills

All, The notes from the meeting are here: https://linaro.atlassian.net/wiki/spaces/HVAC/pages/30311874561/2025-10+Upd… PR #25 has been redone to include Bertrand's commits as well as my own. https://github.com/Linaro/virtio-msg-spec/pull/25 I am most interested to know everyones opinion on the removal of the redundant length fields. I am 60/40 against. Thanks, Bill -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

7 months, 3 weeks

2
1
0 0

Watch Live TV on Apple TV: Everything You Should Know

by andrew100mills＠gmail.com

Wondering does Apple TV have live TV? The answer is yes — but with a twist. Apple TV itself doesn’t stream live channels directly. Instead, it lets you access live TV through different apps and streaming services. Think of it as a smart hub that connects all your favorite entertainment in one place. You can watch live news, sports, and local channels using apps like YouTube TV, Hulu + Live TV, Sling TV, or fuboTV. These apps stream live content right through your Apple TV device, so you never miss your favorite shows or games. Plus, Apple TV’s clean interface and Siri voice control make browsing super easy and fun. If you’re subscribed to Apple TV+, you’ll get original series and movies, but not traditional live channels. To enjoy live TV, just download your preferred streaming app, sign in, and start watching. So, does Apple TV have live TV? Absolutely — through partner apps and services. It’s the perfect choice for cord-cutters who want flexibility, high quality, and convenience in one device. For more tech tips and guides like this, visit Home Tech Nerves and stay tuned for smarter streaming solutions! Visit Now: https://hometechnerves.com/does-apple-tv-have-live-tv/

8 months

1
0
0 0

New pull request for RFCv3 spec

by Bertrand Marquis

Hi, I pushed the following pull request to github: https://github.com/Linaro/virtio-msg-spec/pull/24 It is a proposal to handle some things we agreed on modifying in the spec: - header size 8 byte - unique identifier in header - relax error handling to let bus report errors and be coherent with current linux implementation This is a draft and i am definitely open to comments :-) Cheers Bertrand 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.

8 months

1
0
0 0

[vmsg][RFC V2 PATCH 0/6] virtio: Add support for Virtio message transport

by Viresh Kumar

Hello, I will try to send this upstream early next week. V2: - Don't limit get/set config to 8 bytes only. - Improved direct/indirect message handling. - Take care of EBUSY error during indirect message. - Static assertions. -------------------------8<------------------------- Hello, This RFC series introduces support for a new Virtio transport type: "virtio-msg", as proposed in [1]. Unlike existing transport types like virtio-mmio or virtio-pci which rely on memory-mapped registers, virtio-msg implements transport operations via structured messages. Those messages can be transported through different mechanisms such as mailboxes, shared memory based FIFO or specific protocols such as FF-A on Arm. This series includes: - Core virtio-msg transport support. - Two message transport bus implementations: - virtio-msg-ffa: based on ARM's Firmware Framework for Arm (FF-A). - virtio-msg-loopback: a loopback device for testing and validation. The code is available here for reference: [3] and virtio-msg loopback test setup is explained here: [2]. This series is based on v6.16-rc6 and depends on commit [4] from linux-next. ### Memory Mapping and Reserved Memory Usage The first two patches enhance the reserved-memory subsystem to support attaching struct device`s that do not originate from DT nodes—essential for virtual or dynamically discovered devices like the FF-A or loopback buses. This reserved-memory region enables: - Restricting all DMA-coherent and streaming DMA memory to a controlled range. - Allowing the remote endpoint to pre-map this memory, reducing runtime overhead. - Preventing unintentional data leaks, since memory is typically shared at page granularity. - For the loopback bus, it restricts the portion of kernel memory that can be mapped into userspace, improving safety. Device association with reserved-memory regions is based on DT node naming conventions, such as vmsglb@ or vmsgffa@, similar to the remoteproc framework’s approach. Feedback on the design, API, and approach is welcome. -- Viresh [1] https://lore.kernel.org/all/20250620224426.3923880-2-bill.mills@linaro.org/ [2] https://linaro.atlassian.net/wiki/spaces/HVAC/pages/30104092673 [3] git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/linux.git virtio/msg-rfc-v1 [4] From linux-next: 5be53630b4f0 virtio-mmio: Remove virtqueue list from mmio device Viresh Kumar (6): of: reserved-memory: Add reserved_mem_device_init() of: reserved-memory: Add of_reserved_mem_lookup_by_name virtio: Add support for virtio-msg transport virtio-msg: Add optional userspace interface for message I/O virtio-msg: Add support for FF-A (Firmware Framework for Arm) bus virtio-msg: Add support for loopback bus MAINTAINERS | 7 + drivers/of/of_reserved_mem.c | 91 ++-- drivers/virtio/Kconfig | 34 ++ drivers/virtio/Makefile | 5 + drivers/virtio/virtio_msg.c | 611 +++++++++++++++++++++++++++ drivers/virtio/virtio_msg.h | 88 ++++ drivers/virtio/virtio_msg_ffa.c | 505 ++++++++++++++++++++++ drivers/virtio/virtio_msg_loopback.c | 323 ++++++++++++++ drivers/virtio/virtio_msg_user.c | 119 ++++++ include/linux/of_reserved_mem.h | 13 + include/uapi/linux/virtio_msg.h | 221 ++++++++++ include/uapi/linux/virtio_msg_ffa.h | 94 +++++ include/uapi/linux/virtio_msg_lb.h | 22 + 13 files changed, 2109 insertions(+), 24 deletions(-) create mode 100644 drivers/virtio/virtio_msg.c create mode 100644 drivers/virtio/virtio_msg.h create mode 100644 drivers/virtio/virtio_msg_ffa.c create mode 100644 drivers/virtio/virtio_msg_loopback.c create mode 100644 drivers/virtio/virtio_msg_user.c create mode 100644 include/uapi/linux/virtio_msg.h create mode 100644 include/uapi/linux/virtio_msg_ffa.h create mode 100644 include/uapi/linux/virtio_msg_lb.h -- 2.31.1.272.g89b43f80a514

8 months, 1 week

4
14
0 0

Release v0.6 of hvac-demo

by Bill Mills

All, I have pushed and tagged a new version of the hvac-demo repo. I have also updated the pre-built container image at: docker.io/wmills/hvac-demo Remember you may need to pull the container image again to see the new version: podman pull docker.io/wmills/hvac-demo - or - docker pull docker.io/wmills/hvac-demo Changes include: * added demo-loopback to show virtio-msg-loopback (based on Viresh's work) * added demo-amp-qemu-pci with virtio-msg-amp on an emulated pcie card in QEMU * renamed all the demos to describe the demo instead of numbers * rebased demo-ffa-xen to use Viresh's latest kernel and rust code * other demos are just renamed Old name New name ---------------------------------- new demo-loopback new demo-amp-qemu-pci demo1 demoo-ffa-xen demo2a (deleted) demo2b demo-proxy-qemu demo3 demo-amp-zephyr demo4 demo-amp-dual-linux The following issues are known: 1) demo-ffa-xen hangs or crashes 1 out of 5 or 10 times Just run again if you see this 2) ./Build all does not build linux-virtio-msg-v2, use ./Build all linux-virtio-msg-amp-v2 You do not need to build the demos to run them 3) The timeout in demo-amp-dual-linux to too short for VERY slow systems Most people won't see this issue. I was testing on a RPiv5 Fixes for the last two issues are in the wip-v0.6-fixes branch. -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

10 months

1
0
0 0

[RFC PATCH 0/6] virtio: Add support for Virtio message transport

by Viresh Kumar

Hello, This RFC series introduces support for a new Virtio transport type: "virtio-msg", as proposed in [1]. Unlike existing transport types like virtio-mmio or virtio-pci, which rely on memory-mapped registers, virtio-msg implements transport operations via structured messages. Those messages can be transported through different mechanisms such as mailboxes, shared memory based FIFO or specific protocols such as FF-A on Arm. This series includes: - Core virtio-msg transport support. - Two message transport bus implementations: - virtio-msg-ffa: based on ARM's Firmware Framework for Arm (FF-A). - virtio-msg-loopback: a loopback device for testing and validation. The code is available here for reference: [2] and virtio-msg loopback and FF-A test setups are explained here: [3] and [4]. This series is based on v6.16 and depends on commit [5]. ### Memory Mapping and Reserved Memory Usage The first two patches enhance the reserved-memory subsystem to support attaching struct device`s that do not originate from DT nodes — essential for virtual or dynamically discovered devices like the FF-A or loopback buses. This reserved-memory region enables: - Restricting all DMA-coherent and streaming DMA memory to a controlled range. - Allowing the remote endpoint to pre-map this memory, reducing runtime overhead. - Preventing unintentional data leaks, since memory is typically shared at page granularity. - For the loopback bus, it restricts the portion of kernel memory that can be mapped into userspace, improving safety. Device association with reserved-memory regions is based on DT node naming conventions, such as vmsglb@ or vmsgffa@, similar to the remoteproc framework’s approach. Feedback on the design, API, and approach is welcome. -- Viresh [1] https://lore.kernel.org/all/20250620224426.3923880-2-bill.mills@linaro.org/ [2] git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/linux.git virtio/msg-rfc-v1 [3] https://linaro.atlassian.net/wiki/spaces/HVAC/pages/30104092673 [4] https://linaro.atlassian.net/wiki/spaces/HVAC/pages/29657792513 [5] From linux-next: 5be53630b4f0 virtio-mmio: Remove virtqueue list from mmio device Viresh Kumar (6): of: reserved-memory: Add reserved_mem_device_init() of: reserved-memory: Add of_reserved_mem_lookup_by_name virtio: Add support for virtio-msg transport virtio-msg: Add optional userspace interface for message I/O virtio-msg: Add support for FF-A (Firmware Framework for Arm) bus virtio-msg: Add support for loopback bus MAINTAINERS | 7 + drivers/of/of_reserved_mem.c | 91 +++- drivers/virtio/Kconfig | 34 ++ drivers/virtio/Makefile | 5 + drivers/virtio/virtio_msg.c | 655 +++++++++++++++++++++++++++ drivers/virtio/virtio_msg_ffa.c | 505 +++++++++++++++++++++ drivers/virtio/virtio_msg_internal.h | 88 ++++ drivers/virtio/virtio_msg_loopback.c | 323 +++++++++++++ drivers/virtio/virtio_msg_user.c | 140 ++++++ include/linux/of_reserved_mem.h | 13 + include/uapi/linux/virtio_msg.h | 213 +++++++++ include/uapi/linux/virtio_msg_ffa.h | 94 ++++ include/uapi/linux/virtio_msg_lb.h | 22 + 13 files changed, 2166 insertions(+), 24 deletions(-) create mode 100644 drivers/virtio/virtio_msg.c create mode 100644 drivers/virtio/virtio_msg_ffa.c create mode 100644 drivers/virtio/virtio_msg_internal.h create mode 100644 drivers/virtio/virtio_msg_loopback.c create mode 100644 drivers/virtio/virtio_msg_user.c create mode 100644 include/uapi/linux/virtio_msg.h create mode 100644 include/uapi/linux/virtio_msg_ffa.h create mode 100644 include/uapi/linux/virtio_msg_lb.h -- 2.31.1.272.g89b43f80a514

10 months, 1 week

1
6
0 0

[RFC PATCH 0/6] virtio: Add support for Virtio message transport

by Viresh Kumar

Hi everyone, Over the last few weeks, I have made numerous changes in the design and code to get it ready for mainline. I have now prepared the initial RFC patchset to be sent to LKML. Please have a look and provide your valuable feedback. -------------------------8<------------------------- Hello, This RFC series introduces support for a new Virtio transport type: "virtio-msg", as proposed in [1]. Unlike existing transport types like virtio-mmio or virtio-pci which rely on memory-mapped registers, virtio-msg implements transport operations via structured message exchanges using standard virtqueues. This series includes: - Core virtio-msg transport support. - Two message transport bus implementations: - virtio-msg-ffa: based on ARM's Firmware Framework for Arm (FF-A). - virtio-msg-loopback: a loopback device for testing and validation. The code is available here for reference: [3] and virtio-msg loopback test setup is explained here: [2]. This series is based on v6.16-rc6 and depends on commit [4] from linux-next. ### Memory Mapping and Reserved Memory Usage The first two patches enhance the reserved-memory subsystem to support attaching `struct device`s that do not originate from DT nodes—essential for virtual or dynamically discovered devices like the FF-A or loopback buses. This reserved-memory region enables: - Restricting all DMA-coherent and streaming DMA memory to a controlled range. - Allowing the remote endpoint to pre-map this memory, reducing runtime overhead. - Preventing unintentional data leaks, since memory is typically shared at page granularity. - For the loopback bus, it restricts the portion of kernel memory that can be mapped into userspace, improving safety. Feedback on the design, API, and approach is welcome. -- Viresh [1] https://lore.kernel.org/all/20250620224426.3923880-2-bill.mills@linaro.org/ [2] https://linaro.atlassian.net/wiki/spaces/HVAC/pages/30104092673 [3] git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/linux.git virtio/msg-rfc-v1 [4] From linux-next: 5be53630b4f0 virtio-mmio: Remove virtqueue list from mmio device Viresh Kumar (6): of: reserved-memory: Add reserved_mem_device_init() of: reserved-memory: Add of_reserved_mem_lookup_by_name virtio: Add support for virtio-msg transport virtio-msg: Add optional userspace interface for message I/O virtio-msg: Add support for FF-A (Firmware Framework for Arm) bus virtio-msg: Add support for loopback bus MAINTAINERS | 7 + drivers/of/of_reserved_mem.c | 91 +++-- drivers/virtio/Kconfig | 34 ++ drivers/virtio/Makefile | 5 + drivers/virtio/virtio_msg.c | 546 +++++++++++++++++++++++++++ drivers/virtio/virtio_msg.h | 88 +++++ drivers/virtio/virtio_msg_ffa.c | 501 ++++++++++++++++++++++++ drivers/virtio/virtio_msg_loopback.c | 323 ++++++++++++++++ drivers/virtio/virtio_msg_user.c | 119 ++++++ include/linux/of_reserved_mem.h | 13 + include/uapi/linux/virtio_msg.h | 221 +++++++++++ include/uapi/linux/virtio_msg_ffa.h | 94 +++++ include/uapi/linux/virtio_msg_lb.h | 22 ++ 13 files changed, 2040 insertions(+), 24 deletions(-) create mode 100644 drivers/virtio/virtio_msg.c create mode 100644 drivers/virtio/virtio_msg.h create mode 100644 drivers/virtio/virtio_msg_ffa.c create mode 100644 drivers/virtio/virtio_msg_loopback.c create mode 100644 drivers/virtio/virtio_msg_user.c create mode 100644 include/uapi/linux/virtio_msg.h create mode 100644 include/uapi/linux/virtio_msg_ffa.h create mode 100644 include/uapi/linux/virtio_msg_lb.h -- 2.31.1.272.g89b43f80a514

10 months, 2 weeks

3
20
0 0

Virtio message loopback

by Viresh Kumar

Hello, As discussed yesterday during the call, I have prepared the list of instructions to reproduce my virtio-msg loopback setup. Please give a try and lemme know if something doesn't work. This is based on the latest version of the spec (from Bill's latest pull request today). -- Viresh [1] https://linaro.atlassian.net/wiki/spaces/HVAC/pages/30104092673 -- viresh

11 months, 1 week

2
2
0 0

[PATCH RFC v2 0/1] virtio-msg transport layer

by Bill Mills

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. How much of the bus level should be described in the virtio spec is one item we wish to discuss. This draft takes a middle approach by describing the bus level and defining some standard bus level messages that MAY be used by the bus. It also describes a range of bus messages that are implementation dependent. 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. We are working on two 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 * 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 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-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 * Once developed this can provide a single kernel demo of virtio-msg * [Work has begun on this] * 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 RFC1: * reformated document to better conform to the virtio spec style - created an introduction chapter - created a basic concept chapter - created bus operation and device initialization and operation chapters - reworked description of transport and bus messages - attempted a "compliance chapter" - reused spec macros - switched to MAY/MUST/SHALL/SHOULD wording - eliminate the use of terms front-end and back-end and use driver and device * made the maximum message size variable per bus instance * use "device number" for virtio-msg device instances on the bus instead of adding yet another meaning for "device ID" * added the configuration generation count and its use * described types of things that can be done with bus specific messages such as setup of bus level shared memory and out of band notifications * removed wording of notification being optional at transport level and described bus level notifications of in-band, out-of-band, and polled from driver side bus * removed the ERROR message from transport level. Errors should be handled at the bus level to better match virtio-pci and virtio-mmio * removed bus level reset and status from standard bus messages * replaced bus messages DEVICE_{ADDED,REMOVED} with EVENT_DEVICE * changed names to GET_DEVICE_FEATURES and SET_DRIVER_FEATURES for clarity * made SET_DEVICE_STATE return new state as it may not match * Don't echo back the data in SET_VQUEUE (it cannot change) * defined request/response vs event message id ranges * match field size of next offset and wrap to virtio-{pci,mmio} * added maximum number of virtqueues to DEVICE_INFO * added admin virtqueue and SHM support This series is a work in progress and we acknowledge at least the following issues we need to work on: * Better conformance documentation * Publish an update to Arm FF-A spec that shows virtio-msg binding (work underway) * Publish virtio-msg-amp data structures and messages somewhere * Align implementations to this version and send PATCH v1 (non-rfc) 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, they are not yet aligned with each other nor this version of the spec. [1] https://linaro.atlassian.net/wiki/spaces/HVAC/overview [2] https://github.com/wmamills/hvac-demo [3] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/linux.git/log/?h=vi… [4] https://github.com/edgarigl/qemu/commits/edgar/virtio-msg-new [5] https://github.com/arnopo/open-amp/commits/virtio-msg/ Bill Mills (1): virtio-msg: Add virtio-msg, a message based virtio transport layer content.tex | 1 + transport-msg.tex | 1354 +++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 1355 insertions(+) create mode 100644 transport-msg.tex -- 2.34.1

11 months, 2 weeks

4
5
0 0

PR #20, fix-up pending changes before RFCv2

by Bill Mills

All, The pull request referenced here covers the remaining items needed before sending RFCv2. Please take a look and let me know if you see issues. You can comment in the PR or send email to the list. https://github.com/Linaro/virtio-msg-spec/pull/20 Thanks, Bill -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

11 months, 4 weeks

1
0
0 0

[PATCH] firmware: arm_ffa: Fix struct ffa_indirect_msg_hdr

by Viresh Kumar

As per the spec, one 32 bit reserved entry is missing here, add it. Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> --- include/linux/arm_ffa.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/arm_ffa.h b/include/linux/arm_ffa.h index 5bded24dc24f..e1634897e159 100644 --- a/include/linux/arm_ffa.h +++ b/include/linux/arm_ffa.h @@ -283,6 +283,7 @@ struct ffa_indirect_msg_hdr { u32 offset; u32 send_recv_id; u32 size; + u32 res1; uuid_t uuid; }; -- 2.31.1.272.g89b43f80a514

1 year

1
0
0 0

[PATCH] virtio-mmio: Remove virtqueue list from mmio device

by Viresh Kumar

The MMIO transport implementation creates a list of virtqueues for a virtio device, while the same is already available in the struct virtio_device. Don't create a duplicate list, and use the other one instead. While at it, fix the virtio_device_for_each_vq() macro to accept an argument like "&vm_dev->vdev" (which currently fails to build). Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> --- I have tested this with a Xen/Qemu based setup to test guest to host virtio-i2c communication. Works fine, not sure why this code was added in the first place. drivers/virtio/virtio_mmio.c | 52 +++--------------------------------- include/linux/virtio.h | 2 +- 2 files changed, 4 insertions(+), 50 deletions(-) diff --git a/drivers/virtio/virtio_mmio.c b/drivers/virtio/virtio_mmio.c index 5d78c2d572ab..b152a1eca05a 100644 --- a/drivers/virtio/virtio_mmio.c +++ b/drivers/virtio/virtio_mmio.c @@ -65,7 +65,6 @@ #include <linux/platform_device.h> #include <linux/pm.h> #include <linux/slab.h> -#include <linux/spinlock.h> #include <linux/virtio.h> #include <linux/virtio_config.h> #include <uapi/linux/virtio_mmio.h> @@ -88,22 +87,8 @@ struct virtio_mmio_device { void __iomem *base; unsigned long version; - - /* a list of queues so we can dispatch IRQs */ - spinlock_t lock; - struct list_head virtqueues; -}; - -struct virtio_mmio_vq_info { - /* the actual virtqueue */ - struct virtqueue *vq; - - /* the list node for the virtqueues list */ - struct list_head node; }; - - /* Configuration interface */ static u64 vm_get_features(struct virtio_device *vdev) @@ -300,9 +285,8 @@ static bool vm_notify_with_data(struct virtqueue *vq) static irqreturn_t vm_interrupt(int irq, void *opaque) { struct virtio_mmio_device *vm_dev = opaque; - struct virtio_mmio_vq_info *info; + struct virtqueue *vq; unsigned long status; - unsigned long flags; irqreturn_t ret = IRQ_NONE; /* Read and acknowledge interrupts */ @@ -315,10 +299,8 @@ static irqreturn_t vm_interrupt(int irq, void *opaque) } if (likely(status & VIRTIO_MMIO_INT_VRING)) { - spin_lock_irqsave(&vm_dev->lock, flags); - list_for_each_entry(info, &vm_dev->virtqueues, node) - ret |= vring_interrupt(irq, info->vq); - spin_unlock_irqrestore(&vm_dev->lock, flags); + virtio_device_for_each_vq(&vm_dev->vdev, vq) + ret |= vring_interrupt(irq, vq); } return ret; @@ -329,14 +311,8 @@ static irqreturn_t vm_interrupt(int irq, void *opaque) static void vm_del_vq(struct virtqueue *vq) { struct virtio_mmio_device *vm_dev = to_virtio_mmio_device(vq->vdev); - struct virtio_mmio_vq_info *info = vq->priv; - unsigned long flags; unsigned int index = vq->index; - spin_lock_irqsave(&vm_dev->lock, flags); - list_del(&info->node); - spin_unlock_irqrestore(&vm_dev->lock, flags); - /* Select and deactivate the queue */ writel(index, vm_dev->base + VIRTIO_MMIO_QUEUE_SEL); if (vm_dev->version == 1) { @@ -347,8 +323,6 @@ static void vm_del_vq(struct virtqueue *vq) } vring_del_virtqueue(vq); - - kfree(info); } static void vm_del_vqs(struct virtio_device *vdev) @@ -375,9 +349,7 @@ static struct virtqueue *vm_setup_vq(struct virtio_device *vdev, unsigned int in { struct virtio_mmio_device *vm_dev = to_virtio_mmio_device(vdev); bool (*notify)(struct virtqueue *vq); - struct virtio_mmio_vq_info *info; struct virtqueue *vq; - unsigned long flags; unsigned int num; int err; @@ -399,13 +371,6 @@ static struct virtqueue *vm_setup_vq(struct virtio_device *vdev, unsigned int in goto error_available; } - /* Allocate and fill out our active queue description */ - info = kmalloc(sizeof(*info), GFP_KERNEL); - if (!info) { - err = -ENOMEM; - goto error_kmalloc; - } - num = readl(vm_dev->base + VIRTIO_MMIO_QUEUE_NUM_MAX); if (num == 0) { err = -ENOENT; @@ -463,13 +428,6 @@ static struct virtqueue *vm_setup_vq(struct virtio_device *vdev, unsigned int in writel(1, vm_dev->base + VIRTIO_MMIO_QUEUE_READY); } - vq->priv = info; - info->vq = vq; - - spin_lock_irqsave(&vm_dev->lock, flags); - list_add(&info->node, &vm_dev->virtqueues); - spin_unlock_irqrestore(&vm_dev->lock, flags); - return vq; error_bad_pfn: @@ -481,8 +439,6 @@ static struct virtqueue *vm_setup_vq(struct virtio_device *vdev, unsigned int in writel(0, vm_dev->base + VIRTIO_MMIO_QUEUE_READY); WARN_ON(readl(vm_dev->base + VIRTIO_MMIO_QUEUE_READY)); } - kfree(info); -error_kmalloc: error_available: return ERR_PTR(err); } @@ -627,8 +583,6 @@ static int virtio_mmio_probe(struct platform_device *pdev) vm_dev->vdev.dev.release = virtio_mmio_release_dev; vm_dev->vdev.config = &virtio_mmio_config_ops; vm_dev->pdev = pdev; - INIT_LIST_HEAD(&vm_dev->virtqueues); - spin_lock_init(&vm_dev->lock); vm_dev->base = devm_platform_ioremap_resource(pdev, 0); if (IS_ERR(vm_dev->base)) { diff --git a/include/linux/virtio.h b/include/linux/virtio.h index 64cb4b04be7a..8b745ce0cf5f 100644 --- a/include/linux/virtio.h +++ b/include/linux/virtio.h @@ -196,7 +196,7 @@ int virtio_device_reset_done(struct virtio_device *dev); size_t virtio_max_dma_size(const struct virtio_device *vdev); #define virtio_device_for_each_vq(vdev, vq) \ - list_for_each_entry(vq, &vdev->vqs, list) + list_for_each_entry(vq, &(vdev)->vqs, list) /** * struct virtio_driver - operations for a virtio I/O driver -- 2.31.1.272.g89b43f80a514

1 year

1
0
0 0

Re: Discussion Virtio with pKVM / FFA

by Viresh Kumar

Hello everyone, Moving the discussion from google doc [1] to email (Sorry, it was becoming impossible to follow and reply there). FWIW, I am not the best person to answer all questions here, that would be Armelle as she understand the requirements and the end goal much better than I do. I can though try to answer from kernel's perspective, based on whatever implementation we have right now. AFAIK, the broad idea is to implement two virtio communication paths from pVM, one to the Linux host (via virtio-pci) and another one to Trusty (via virtio-msg-ffa). In order to not take performance hit at runtime (to map io buffers), the idea is to map whatever amount of memory we can at the beginning and then keep allocating from there. Current setup: What we have achieved until now is virtio-msg communication between host and trusty. We have implemented FFA specific dma-hal [2] to perform FFA memory sharing with trusty. With "reserved-mem" and "memory-region" DT entries (not sure if that is the final solution), we are able to allocate memory the FFA device (which represents bus for all the enumerated devices between trusty/host). This memory is shared with trusty at probe time (from virtio-msg-ffa layer) and the DMA hal later allocates memory from there for coherent allocations and bounce buffers. This works just fine right now. Now looking at "dynamic mapping" section in [1] we are not sure if that will work fine for the end use case, pVM to trusty. It looks like the coco implementation will always end up using dma encrypt/decrypt when a pVM is running and share the memory with host, even when all we want to do is share with trusty. Is that understanding correct ? We would also want to establish virtio-pci (existing tech) based communication between pVM and host, which should use mem decrypt path (?). I am not sure if we need contiguous PA here, contiguous IPA should be sufficient, Armelle? We are also looking for further suggestions to improve the design, as my understanding of memory mapping, dma hal etc. is limited, and maybe there are better ways to do this. -- Viresh [1] https://docs.google.com/document/d/1KyxclKngQ0MShX8Q1YPstZQVIDIctkxfj6lQ0V3… [2] https://web.git.kernel.org/pub/scm/linux/kernel/git/vireshk/linux.git/tree/…

1 year, 1 month

4
14
0 0

My spec review list

by Bill Mills

Bertrand, I know you are on vacation but here is my full list. It took longer to flesh out from my pencil notes than I thought. While you are gone I will try to tackle all of these these in a PR w/ one commit per item. I will at least get to some of them. I will create issues for things I think need discussion. Thanks, Bill -------------- Global: * Eliminate all use of "frontend" and "backend", can use device side and driver side when just device or driver is not enough * Use device number (dev_num) instead of Device ID to avoid confusion with device type (called Device ID in spec) * Address out of band notification as an option, any polling that is required should be done by the bus implementation, not the common layer. * for all EVENT_ messages change "does not require a response" to "does not have a response". There is no optional response; a response is forbidden. 4.4.2.1 Bus level feature bits * are these local to the bus implementation or communicated to the virtio-msg transport layer? (I vote local) * what would be an example of a bus feature that would need to be known at the common layer that is NOT a device feature? 4.4.2.1.1 max message size definition. Does this include or exclude headers added by the bus implementation? I suggest it excludes it. 4.4.2.1.1 max message size of 64K * This seems a bit excessive. It may cause people to invent new uses for the message channel that we do not intend. * Should we lower the max message size? * Should we add a note that says no use of message sizes above 288 bytes is envisioned? (288 = 256 bytes of config data plus 32 bytes for message overhead. Right now message overhead is 18 for SET_CONFIG so 32 is plenty but 16 is too small.) 4.4.2.3 Config Generation Count * (self note: Config gen count only needs to be incremented once per *driver visible* change A device can do a whole set of changes and MAY/SHOULD only increment the gen count by one until the new gen count is published to the other side via EVENT_CONFIG or GET/SET_CONFIG However this is basically the same thing from the spec POV. ) * Should we say that Config gen count starts at 0 (SHOULD? MUST?) * Does config gen count reset at device reset or not? If not then maybe we don't say it starts at zero either and the driver MUST query it You do not need to know the config gen counter to GET_CONFIG, only to SET_CONFIG 4.4.2.5.1 Error codes * Are error codes aligned to admin queues yet? 4.4.2.6 Bus vs Transport messages * Mention shared memory setup and out of band notification in bus message overview * Mention bus implementation specific messages in bus message overview * Remove BUS_MSG_STATUS for now (or allow request/response and maybe add EVENT_ version w/o response) 4.4.2.8 dev_id to dev_num or dev_number 4.4.3.3 Resetting the BUS * We decided to drop this for now * When we do it graceful and abortive reset should be handled * For graceful device initiated reset, it should be handled by setting state to NEEDS_RESET 4.4.4.2 Device Info * add max number of virtqueues (or define a null response for GET_VQ) 4.4.4.3.1 error if *index* is beyond elsewhere it says pad with zeros (why do we need this just return zeros) 4.4.4.5 we need max number of virtqueue in DEVICE_INFO OR return maximum size of 0 for all unsupported indexes on GET and ERROR on set 4.4.4.6 Mention Device status change w/o config change as another possible reason to get 4.4.4.7 Actually virtqueues and come and go during the life of the device. The STATUS can (should?) be set to DRIVER OK before any virtqueues are set. 4.4.5.1 * what are NOTIFY_ON_AVAIL and NEGOCIATE_DATA (sp)? These appear no where else in the spec. * all existing transports have a way to notify driver -> device per virtqueue 4.4.5.1.1 * virtqueue id is always present * If VIRTIO_F_NOTIFICATION_DATA has not been negotiated then next_off and next_wrap should be 0 in message (Bertrand did not like using msg_length to exclude them). * We might want to update the text for a better description or just delete it and leave it to the VIRTIO_F_NOTIFICATION_DATA feature description. * Should we support VIRTIO_F_NOTIF_CONFIG_DATA? If so then virtqueue_index can be vq_notif_config_data instead 4.4.5.2 Device Notifications * Maybe here would be a place to mention OoB notifications and polling? * I don't think this is a MAY from the transport level. * The Bus MUST give these messages to the transport level. It can get them from messages on the bus, from OoB notifications, or generating them periodically to stimulate polling. 4.4.5.2.1 EVENT_CONFIG * sent on config OR STATUS change * we talked about a new version of this message with no data to use for OoB and polling stimulation 4.4.5.2.2 EVENT_USED * should we define virtqueue index of -1 as "all virtqueues? * we could put the loop in the bus instead, this would handle the case of 2 virtqueues on MSIX #2 and 1 one virtqueue on MSIX #3 4.4.5.3 Configuration Changes During Operation * Feature re-negotiation is not allowed by the spec. drop this part of the text From 2.2 Feature Bits: """ Each virtio device offers all the features it understands. During device initialization, the driver reads this and tells the device the subset that it accepts. The only way to renegotiate is to reset the device. """ 4.4.5.4 Device Rest and Shutdown * reword last sentence, it is valid to not re-init the device if your not going to use it again 4.4.5.4.1 Device-Initated Rest * match the other transports here. The device sends an async status change with DEVICE_NEEDS_RESET set and waits for driver to reset the device via a SET_STATUS of 0. 4.4.6.1.1 Bigger gap between request response messages and EVENT_ messages * Not a lot of space to add new request/response messages * Renumber to 0x80, 0x81, 0x82 4.4.6.2 VIRTIO_MSG_ERROR * no way to match an error to multiple outstanding messages of the same type ** Right now we assume we only have one outstanding request message per device. This will probibly be true in Linux. However a different OS could choose to do multiple SET_VQ in parrallel (for example). There is no way to coordinate which SET_VQ a VIRTIO_MSG_ERROR pairs with. ** Solutions 1) add a transaction id at the bus level and do all matching based on that 2) add a transaction id at the transport common header 3) add another field to the error message that would differenciate (index for VQ). This makes matching logic per msg_id 4) assume one message per device serialization 5) #4 UNLESS #1 4.4.6.3 VIRTIO_MSG_GET_DEVICE_INFO * add max num virtqueues * add number of Shared memory Regions (section 2.3) (do this in same patch that adds GET_SHM message) 4.4.6.4 VIRTIO_MSG_GET_FEATURES * Most transports have device features and driver features and allow both to be read. device features always reflect the capabilities of the device. driver features are written with the feastures the driver wants to use and read back the negotiated features It is clear that the SET_FEATURES writes the driver desired features and gets back the negotiated features What does GET_FEATURES read? I presume it reads device features before negotiation and negotiated features after negotiation * Should we add a param to specify DEVICE to DRIVER features to the GET_FEATURES message for parity with other transports? 4.4.6.4 & .5 * make it clear that a feature block is a set of 32 feature bits * feature bits beyond the number of max feature bits always read as zero 4.4.6.9 SET_DEVICE_STATUS * return the new status. It is vald for the device to refuse to set the FEATURES_OK bit. (3.1.1 number 6) A set status might also cause a DEVICE_NEEDS_RESET. 4.4.6.11 SET_VQUEUE * why is the info echoed back, can it ever change? 4.4.6.12 RESET_VQUEUE * Does this need to be negotiated? * VIRTIO_F_RING_RESET is the feature bit 4.4.6.13 VIRTIO_MSG_EVENT_CONFIG * see above about adding no data version of this 4.4.6.14 VIRTIO_MSG_EVENT_AVAIL * Next offset and next wrap should be 0 if not negotiated * should we add virtqueue index == -1 means all virtqueues (this would be use on device side between bus and transport for OoB or polling stimulation 4.4.6.15 VIRTIO_MSG_EVENT_USED * should we add virtqueue index == -1 means all virtqueues (this would be use on driver side bus and transport for OoB or polling stimulation and gives parity with virtio-mmio and base level of virtio-pci) 4.4.7.2 BUS_MSG_GET_DEVICES * needs better description of bit packing * offset is in bits, bytes, 32 bit words?? * number of device_nums requested, this is number of bits or number of packed data bytes / words. Must be multiple of * better description on how bits are packed into array 4.4.7.4 BUS_MSG_DEVICE_REMOVED * how do we handle a graceful eject vs an abortive one? * add indicator A) already removed, deal with it B) removing now, don't start new data transfers, I will finish existing ones C) removing soon, write any dirty data and then remove or reset device yourself. May escalate to B or A if driver does not take action D) ask to eject, can be refused Add BUS_MSG_DEVICE_REMOVE as driver to device MSG. Driver side say it is done with this device. 4.4.7.6 BUS_MSG_STATUS * lots of problems with this being a no response message * remove from spec for now 4.4.8.* Conformance (Initial thoughts. I did not review this section rigorously.) * Most of this is "do the right thing" without any specifics. * Other transports spread the requirements into the various sections. We should probibly do the same. One thing that needs to be specified is when to return ERROR and when to return "benign data". Ex: getting feature bits that don't exist, return zeros or return error Ex: setting features bit that don't exist to zero; OK or error Ex: setting feature bits that don't exist to 1; return negotiated 0 or return error The mmio transport will just return zeros for these cases. Why can't we? * We need to thing about notifications and events. I don't think they are optional. They are not optional in virtio-mmio and virtio-pci. 4.4.8.2.1 General Transport Requirements I don't see a precedent for common requirements. If no precedent is found, repeat the requirements in device and driver sections. 4.4.8.6 Versioning and Forward Compatibility "" If a bus instance or device does not support an advanced feature, it MUST reject or ignore those requests cleanly using VIRTIO_MSG_ERROR, rather than undefined behavior. """ Reject is via MSG_ERROR that is clear. If we negotiate a protocol version do we expect to send unknown messages? The option to Ignore messages we don't understand seems wrong as we don't know if they are important. -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

1 year, 2 months

1
0
0 0

Major push to the spec

by Bertrand Marquis

Hi Everyone, I pushed a major change to the pull request for the spec here: https://github.com/Linaro/virtio-msg-spec/pull/16 I reworked the chapters and the content to look a lot more like other virtio transports and follow the sentence convention (MUST, SHALL, SHOULD). Some sentences have been reworded with the help of chatgpt so we need to have a careful review of this but i think it looks a lot better than before. please review based on the final content and not using the tree of patches as the last one is more or less rewriting everything. Some things to think of: - message format description: should we switch to structures instead of tables ? I did that for the header and channel I/O is using structures which might look better - global terminology: i struggle a bit between driver/device vs frontend/backend and we must have a check on the coherency - compliance: this is the bare output of chatgpt more for discussing than keeping it but it could give us ideas if we want to have something (Warning the compliance chapter content might be wrong). As always: any comments are welcome :-) Cheers Bertrand 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.

1 year, 2 months

2
2
0 0

Virtio-msg over FFA on Xen

by Edgar E. Iglesias

Hi all, I was wondering if the virtio-msg demos we have for FFA work on Xen? I have some vague memory that they do. I wonder if I can use the same lower-level virtio-msg-bus or ffa calls to move messages between a DomU/Linux and a QEMU backend in Dom0? Can someone point me to the code? Or documentation? Thanks! Best regards, Edgar

1 year, 2 months

3
3
0 0

Virtio Message Version Handling

by Bertrand Marquis

Hi Everyone, As you know we have a pending subject around Version handling to solve to have some kind of "stable" version of the protocol and I think we have a bit over engineered this so far so i will try to explain my current train of thoughts so that we could have a productive discussion on Thursday. What are other transports doing and why ? - PCI: there is no real protocol version. Capabilities are used and there is only one used for Legacy devices - MMIO: One version register which an be 1 or 2, read only from the driver which is used to inform a driver of the layout of the registers. There is no negociation - Channel I/O: A revision, a length and some way to set additional options depending on the revision. The driver is here telling to the device which revision of the protocol it wants to use and the device just say no if it does not support what the driver wants. Once selected any change must be rejected by the device and the driver must begin by setting it. Somehow the virtio spec says that this is per device as the only change was a status message not existing but it is clear that this must be handled at the transport level and not in a specific driver. What we need ? I think we need something very close to what Channel I/O is defining and it would be a good idea to do reuse the same principles: - the driver side sets the revision - the device side just say "Error" if it does not support what is requested - once the revision is set, only a reset can allow to change it - driver side should start with highest revision and go down until it finds a revision it supports Now I think that having this per device is not useful because we want to have a generic transport and having different sets of messages per device due to different revision seems like a complexity we do not need. So i think this is something that we should offload at the bus level and define the following: - A bus implementation must inform the virtio message generic transport of the version of the protocol to be used for a specific bus device instance (ie all devices on this instance will use the same protocol version). This is to be done through an implementation defined way. - A bus implementation must inform the virtio message generic transport of the maximum message size its support through an implementation defined way. This can also be per bus device instance. - It is the bus driver responsibility to negociate a version and maximum message size with a bus device instance. - It is the bus device responsibility to know which versions are supported by its own virtio message generic implementation. Follwing those principles i would propose to do the following changes in the specification: - remove the VIRTIO_MSG_VERSION message - introduce a BUS_MSG_VERSION message with more or less the same definition as the current VIRTIO_MSG_VERSION (only simplifying by saying that the driver sets a version and device say yes or no, the size would work as it is now) Some questions for discussion: - Do you think it is ok to move this to the BUS or should we keep it in the generic layer to be more "coherent" with other transports ? - Should we provision something like the "data" part in Channel I/O to have options on a specific revision ? - Anything else ? Cheers Bertrand 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.

1 year, 2 months

2
1
0 0

New Pull Request on top of RFC

by Bertrand Marquis

Hi Everyone, I pushed a new pull request to github on top of the current RFC status: https://github.com/Linaro/virtio-msg-spec/pull/13 This includes changes to handle some of the issues raised in github: - have a version of the protocol - have a variable message size - have a configuration generation count - give hint that bus implementation can be used for memory sharing or use of out of band notifications Any comment is welcome :-) Cheers Bertrand 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.

1 year, 3 months

1
0
0 0

RFC status

by Bill Mills

All, The RFC went out a bit ago. I updated it based on Bertrand's and Arnaud's suggestions (cover letter, commit description, and s/request/requests/ only). (I also fixed a s/massage/message/ in the cover letter.) Going forward the new baseline for spec work will be virtio-msg-rfc1. This branch is now the default at the linaro repo [1]. Please target all new pull requests to this branch. The virtio-msg-alpha branch is now frozen but will be kept for reference. Thanks, Bill [1] https://github.com/Linaro/virtio-msg-spec -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

1 year, 3 months

3
2
0 0

Demo Status

by Bill Mills

All, I have updated the hvac-demo repo [1] with a new version. This version is tagged: v0.5 The following outlines the changes since Jan 27: * The demos can now be run on an arm64 host (I tested with an AWS EC2 m7g.2xlarge instance) (x86_64 testing was done on my desktop and AWS EC2 m7i.2xlarge instances) * Pre-setup container images (amd64 & arm64) are published at docker.io/wmills/havc-demo * A convenience script ./container was added to make it easier to run a container with a mounted directory (This is an alternative to using the published container images and suggested for building the demos) * The ./container flow now requires the user to run ./setup themselves (The pre-built container images already have ./setup done for both "run" and "build") * Fixes found from Dan's testing * Building demo1 * Running demo3 * Running demo4 * Fixes found from Alex's testing (running on Debian-12 w/o container and using tmux already) * Handle tmux server already running * Isolate from users .tmux.conf and default server * (These fixes are not needed to run in a container) * I have tested with podman and docker * Most of my testing was done on clean EC2 machines w/ Ubuntu 24.04, both x86_64 and arm64 * I also used my x86_64 desktop w/ Ubuntu 22.04 * I tested running the docker.io/wmills/hvac-demo images and the ./container flow * Updated README.MD with simplified instructions including above Thanks, Bill [1] https://github.com/wmamills/hvac-demo.git -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

1 year, 3 months

1
0
0 0

Demo1 not running

by Bertrand Marquis

Hi, I just tried to run demo1 from a docker setup. I can run the demo1 using docker but the demo does not work (some error 95 in kernel transmitting FF-A messages, it went out to far so i could not copy paste it). Cheers Bertrand 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.

1 year, 3 months

2
5
0 0

[PATCH RFC v1 0/1] virtio-msg transport layer

by Bill Mills

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 can be shared by all virtio-msg bus implementations and defines the messages exchanged between the driver and a device. 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. How much of the bus level should be described in the virtio spec is one item we wish to discuss. This draft takes a middle approach by describing the bus level and defining some standard bus level messages that MAY be used by the bus. It also describes a range of bus messages that are implementation dependent. 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. We are working on two 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 * 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 We also anticipate a third: * 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 This series is a work in progress and we acknowledge at least the following issues we need to work on: * Conform to virtio spec nouns (device/driver vs frontend/backend) and verbs (must/may) * Perhaps move error definition elsewhere it the spec and align on its symbols and numeric values * Allow massage size to be greater than 40 bytes and allow bus implementations to define their max message size * Add a way to discover the protocol version * Add a better description of the types of things a bus can do, specifically including out-of-band notification and memory area sharing/discovery * Maybe redo configuration generation handling 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, they are not yet aligned with each other nor this version of the spec. [1] https://linaro.atlassian.net/wiki/spaces/HVAC/overview [2] https://github.com/wmamills/hvac-demo [3] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/linux.git/log/?h=vi… [4] https://github.com/edgarigl/qemu/commits/edgar/virtio-msg-new [5] https://github.com/arnopo/open-amp/commits/virtio-msg/ Bill Mills (1): virtio-msg: Add virtio-msg, a message based virtio transport layer content.tex | 1 + transport-msg.tex | 680 ++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 681 insertions(+) create mode 100644 transport-msg.tex -- 2.34.1

1 year, 3 months

3
6
0 0

Re: How to send VIRTIO_MSG_EVENT_USED ?

by Andrei Homescu

Hi Viresh, I'll try to respond to your first question: indirect messages require FF-A notifications, and Trusty does not support those either. The problem isn't Trusty specifically, but the layers between it and Linux: the hypervisor and SPMC. To be as specific as I can: Hafnium supports notifications, but others don't. For now, we'll need to work around this in virtio-msg-ffa with direct messages and polling. Andrei Homescu

1 year, 3 months

3
3
0 0

How to send VIRTIO_MSG_EVENT_USED ?

by Viresh Kumar

Hi Ayrton / Armelle, I tried to investigate about how to make VIRTIO_MSG_EVENT_USED work without indirect FFA messages. - Firstly, I am still not sure if I fully understand why indirect messages can't be implemented on Trustee side ? I know it was discussed a bit in the call, but I don't remember any of it :( - If we want to do polling of the virtqueues, then it needs to be done on the driver side (vsock), I don't see how I can generalize it and do it from virtio-msg-ffa layer. The driver needs to do something like this for the virtqueue: while (1) { /* Try to get a buffer from the virtqueue */ buf = virtqueue_get_buf(vq, &len); if (buf) { // Handle the received buffer break; } /* Avoid busy looping with a small delay */ cpu_relax(); } - The other idea discussed on the call was about always queuing a direct message for a FFA device (not virtio device) for EVENT_USED message. Once the trustee side has an event to send, it can respond to this request. I was thinking if this may block the CPU for ever with the SMC call, but I don't think that is the case. The FFA layer makes the SMC call, checks its return value and sleeps for a ms, and tries again. With this the CPU will schedule other work as soon as it can. And looks like we support sending multiple direct messages concurrently too, so while a thread is waiting for a response to EVENT_USED message, we can keep sending other messages. If we want to support this, will this be part of the spec ? Bertrand ? - Any other ideas on how to get this solved ? -- viresh

1 year, 3 months

2
5
0 0

RFC update

by Bill Mills

All, You will soon receive an email with the RFC series in its current state. This is a test run; a draft of RFC just for members of this list. If you see anything in the cover letter or commit message that you wish to change please let me know by Monday at 4pm US Eastern time. If you wish to be added to the Signed-off-by list or just the CC list please let me know by the same deadline. Please specify which. It would be good to include someone from Google (even if only in the CC). Changes to the actual patch content is out of scope for now. On Tuesday I will explain more about the branching and PR strategy going forward. For now I am sending the RFC from a branch not yet on the Linaro github. Thanks, Bill -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

1 year, 3 months

1
1
0 0

Call for spec review

by Bill Mills

All, Deadline for issues and PRs: Wednesday Feb 12 Discussion: Thursday Feb 13 RFC Target: Friday Feb 21 We want to publish the first draft of the virtio-msg changes to the virtio spec list as an RFC. We want to make sure: 1) It describes what we are doing 2) Is complete enough for virtio knowledgeable people to understand 3) _We_ don't need big changes* * Reviewers may ask for big changes and we need to be prepared for that. But we need to have our thinking on the same page collectively as much as possible. The work-in-progress spec is here: https://github.com/Linaro/virtio-msg-spec The most recent rendered pdf is here: https://github.com/Linaro/virtio-msg-spec/releases In addition there is pull request #5 that adds most of the things we spoke of in our Dublin sprint: https://github.com/Linaro/virtio-msg-spec/pull/5 All changes are in the file transport-msg.tex (There is one change to content.tex to include the new file) Providing feedback: Unlike the upstream spec, we can use github issues and github pull requests to manage changes within this group. Then one of us (myself or Bertrand most likely) will send to upstream virtio spec mailing list. To provide your feedback please create an issue or a PR. For small changes it is probibly easier to just create a PR with the exact wording you want. You can bundle a number commits into one PR but try to keep each commit to one topic or one section. After the RFC most of the interaction will move to virtio-comment(a)lists.linux.dev so please subscribe now. See the upstream README for details: https://github.com/oasis-tcs/virtio-spec/blob/master/README.md Thanks, Bill -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

1 year, 4 months

2
1
0 0

[PATCH 1/2] firmware: arm_ffa: Partition info can returns self as well

by Viresh Kumar

Partition info may return self partition as well (specially with newer versions of FFA spec), skip adding it twice. Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> --- Rebased over: 9967e35eb1cbdb8d0c0bae3f54401d806700e6b6.1732255888.git.viresh.kumar(a)linaro.org drivers/firmware/arm_ffa/driver.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c index 34d9a54b6a77..b824c7c024fd 100644 --- a/drivers/firmware/arm_ffa/driver.c +++ b/drivers/firmware/arm_ffa/driver.c @@ -1424,6 +1424,9 @@ static int ffa_setup_partitions(void) xa_init(&drv_info->partition_info); for (idx = 0, tpbuf = pbuf; idx < count; idx++, tpbuf++) { + if (drv_info->vm_id == tpbuf->id) + continue; + /* Note that if the UUID will be uuid_null, that will require * ffa_bus_notifier() to find the UUID of this partition id * with help of ffa_device_match_uuid(). FF-A v1.1 and above -- 2.31.1.272.g89b43f80a514

1 year, 4 months

1
1
0 0

[PATCH 0/3] firmware: arm_ffa: Add DT support

by Viresh Kumar

Hello, This series proposes basic DT bindings for FFA devices, and sets up the of_node and dma_configure() callback for the devices. Viresh Kumar (3): dt-bindings: firmware: Add bindings for ARM FFA firmware: arm_ffa: Setup of_node for ffa devices firmware: arm_ffa: Provide .dma_configure() .../devicetree/bindings/firmware/arm,ffa.yaml | 75 +++++++++++++++++++ drivers/firmware/arm_ffa/bus.c | 39 ++++++++++ 2 files changed, 114 insertions(+) create mode 100644 Documentation/devicetree/bindings/firmware/arm,ffa.yaml -- 2.31.1.272.g89b43f80a514

1 year, 4 months

1
3
0 0

Upstream changes

by Viresh Kumar

Hi, Was wondering what email id I can Cc for my upstream changes related to virtio-msg ? Can virtio-msg(a)lists.linaro.org be cc'd ? Does it require subscription (anyone should be able to reply to an upstream change and shouldn't receive a notice about subscription). Not that I am upstreaming virtio-msg yet, but I do occasionally send generic cleanups to the list [0] [1], which isn't reaching others from the project. -- viresh [0] https://lore.kernel.org/all/9967e35eb1cbdb8d0c0bae3f54401d806700e6b6.173225… [1] https://lore.kernel.org/all/e3dd8042ac680bd74b6580c25df855d092079c18.173710…

1 year, 4 months

2
1
0 0

[PATCH 0/2] firmware: arm_ffa: DT bindings and reserved-mem support

by Viresh Kumar

Hello, I would like send this upstream next week, any feedback would be welcome before that. Thanks. Viresh Kumar (2): dt-bindings: firmware: Add bindings for ARM FFA firmware: arm_ffa: Setup of_node for ffa devices .../devicetree/bindings/firmware/arm,ffa.yaml | 75 +++++++++++++++++++ drivers/firmware/arm_ffa/bus.c | 30 ++++++++ 2 files changed, 105 insertions(+) create mode 100644 Documentation/devicetree/bindings/firmware/arm,ffa.yaml -- 2.31.1.272.g89b43f80a514

1 year, 4 months

1
3
0 0

Push to GitHub spec and questions

by Bertrand Marquis

Hi Guys, Happy new Year everyone. I am travelling this week so i will not participate to the meeting but i pushed some changes to the specification in Alex Github mirror. Those are introducing the error message in virtio-msg and some attempt to define the first bus messages. The push contains some TODOs for which i would need some answers or ideas so feel free to look and tell me. Also i wrote down a pending request to get an INT back when a notification is sent in case it cannot be sent and we will need to discuss it as adding an answer to EVENT messages would make those message synchronous which might not be the right idea. In the Bus to Transport interface definition of the google document, I did include an int return code when a message is sent by the transport and this could be used to signal back an error easily where posting a generated message back could introduce more complexity. This is just some thinking on my side and happy to discuss this in 2 weeks or by mail before that. Regards Bertrand 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.

1 year, 4 months

1
0
0 0

STMicroelectronics demo

by Arnaud POULIQUEN

Hello, As discussed yesterday, here are the links to my code demonstrating access from Linux to two RAMs exposed by Zephyr on a remote processor. Even though the code is in a draft state, the demo is now working. The associated README is available here: https://github.com/arnopo/openamp-system-reference/blob/virtio-msg/examples… I have also attached a few slides that give an overview of the software architecture. Links to my github: Linux: remoteproc-virtio-msg driver + virtio hacks https://github.com/arnopo/linux/commits/virtio-msg/ Zephyr : virtio-i2c device + virtio-msg remoteproc device https://github.com/arnopo/open-amp-zephyr/tree/virtio_msg Open-amp library: virtio-i2c + virtio-msg + virtio msg bus + amp-queue https://github.com/arnopo/open-amp/tree/virtio-msg Openamp-system-reference: zephyr I2C ram example https://github.com/arnopo/openamp-system-reference/tree/virtio-msg I wish you a good end of the year Regards, Arnaud

1 year, 5 months

1
0
0 0

Virtio-msg AMP on AMD HW

by Iglesias, Edgar

Hi all, Sharing a couple of slides and my current repos. I'll post instructions on how to reproduce some time next week. Linux: https://github.com/edgarigl/linux/tree/edgari/virtio-msg-sapphire https://github.com/edgarigl/linux/tree/edgari/virtio-msg-versal QEMU: https://github.com/edgarigl/qemu/tree/edgar/virtio-msg-new Bill, this QEMU is rebased with something newer than my other edgar/virtio-msg. I recall you requested a rebase in Dublin! Best regards, Edgar

1 year, 6 months

1
0
0 0

Setup: Virtio-msg FFA with Xen

by Viresh Kumar

Hi everyone, I hope all interested parties are part of the previously created list. Based on the discussions we had previously, where I was struggling to find a setup where I can test virtio-msg with FFA (or something more realistic than hacked-up MMIO), I decided to go ahead and make use of Bertrand's Xen patches with Linux based host and guest VMs. I now have a working setup with Bertrand's Xen patches, where we can do FFA I was able to reuse my earlier setup (where we tested I2C with MMIO traps) based virtio communication guest and host kernels. I have created another page [1] (similar to previous one) for curious ones to replicate it. This would work just fine for Vsock as well, which I tested earlier with the backend from vhost-device crate. -- viresh [1] https://linaro.atlassian.net/wiki/spaces/HVAC/pages/29657792513/2024-11+ker…

1 year, 6 months

2
3
0 0

VirtIO Message specification repo

by Alex Bennée

Hi All, I've forked the VirtIO specification into a Linaro repo for us to work on it: https://github.com/Linaro/virtio-msg-spec I've set the default branch to "virtio-msg-alpha" with the intention of re-basing and squashing commits before we post to the list. Once PRs are merged it triggers a rebuild of the draft spec which you can find in: https://github.com/Linaro/virtio-msg-spec/releases Hopefully the working-draft just gets overwritten each time. -- Alex Bennée Virtualisation Tech Lead @ Linaro

1 year, 6 months

1
0
0 0

Reminder: no meeting today

by Bill Mills

All, Today's meeting was canceled. I did it in an outlook friendly manner, but I have been told some calendars still show the meeting. Next meeting will be in two weeks. Thanks, Bill

1 year, 7 months

1
0
0 0

First draft of markdown design document

by Bertrand Marquis

Hi Everyone, Enclosed you will find a first draft of a design document for the virtio message transport and the bus concept. I took the content from the Google doc and turn it into a markdown and i remove the parts not really needed and reoganized a bit. I also modified the tables to make them easier to read in text format and split the messages format table in several chapters per message. This document is not intended to be in a form compatible with the virtio specification. This is a first draft and any comment is welcome. Cheers Bertrand 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.

1 year, 8 months

2
1
0 0

Re: Welcome to the "Virtio-msg" mailing list

by Arnaud POULIQUEN

Hi, I'm looking for the latest version of the spec. I have a draft version (2024-04-19) that seems not up to date, and I did not find a link that points to the latest version in Confluence. Could someone share the latest version with me? Thanks in advance, Arnaud > -----Original Message----- > From: virtio-msg-request(a)lists.linaro.org <virtio-msg- > request(a)lists.linaro.org> > Sent: Wednesday, September 11, 2024 3:21 PM > To: Arnaud POULIQUEN <arnaud.pouliquen(a)st.com> > Subject: Welcome to the "Virtio-msg" mailing list > > Welcome to the "Virtio-msg" mailing list! > > To post to this list, send your message to: > > virtio-msg(a)lists.linaro.org > > You can unsubscribe or make adjustments to your options via email by > sending a message to: > > virtio-msg-request(a)lists.linaro.org > > with the word 'help' in the subject or body (don't include the quotes), and > you will get back a message with instructions. You will need your password > to change your options, but for security purposes, this password is not > included here. If you have forgotten your password you will need to reset it > via the web UI. ST Restricted

1 year, 8 months

2
1
0 0

Test message

by Bill Mills

Just a test. Dan let me know if you see this. Bill -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

1 year, 8 months

1
0
0 0

2026

2025

2024