Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Note

This page will be updated during the month and is not final until after the 1st week of December.

Summary of Month

...

Highlights

  • Prototype a kernel level driver for ivshmem that can exchange messages with QEMU’s virtio-msg-ivshmem mode

...

  • Held a sprint between AMD, Arm, and Linaro the first week of November

  • An initial implementation of virtio-msg via FFA for Xen DOMU to Xen DOM0

  • AMD has used the Linaro kernel prototypes on real HW for X86 + ARM via PCIe

Issues/Changes

  • 1 week of conference and 1 week of vacation limited the amount of work in November

Jira Legacy
serverSystem Jira
columnskey,summary,type,resolution
columnIdsissuekey,summary,issuetype,resolution
maximumIssues30
jqlQueryproject = HVAC AND status = Closed AND resolved >= endOfMonth("-3") "2024/11/09" AND resolved <= endOfMonth("-1") "2024/12/08"
serverId59107c6f-1e52-32bc-b58f-400d54bba998

...

(Intro slides on front page of project were updated)

Meeting notes

...

  • Follow up on mailing list virtio-msg@lists.linaro.org

  • Making the working spec available to all

    • Bertrand has published host first darft of the markdown format to the list

    • Can we host this markdown format in git somewhere? (w/ images etc)

    • Can we publish a snapshot of the PDF on the HVAC home page util another form is ready?

  • Updates from Bill

  • Updates from Edgar?

  • Updates from Lei?

  • Updates from others?

Actions:

Meeting notes October 24th

...

Notice: no meeting on Nov 7th

...

Updates from Bill

  • I have a kernel that can send a GET_STATUS msg to Edgar’s QEMU on another machine and receive the response.

  • Screenshot from 2024-10-24 09-08-43.pngImage Removed

  • Next steps: deferred RX processing and hooking to Viresh’s virtio-msg common code

  • Note: this code is ugly and prototype quality, Edgar and I need to agree on common shared memory format that will remove hard-coded values

  • Corresponding system level code is here. Each of these branches (kernel and demo) will be rebased as I go along.

  • Note: This will be the first time we interoperate between Authors. So far we have tested Edgar to Edgar and Viresh to Viresh

...

Updates from Edgar?

...

Updates from Lei?

...

Updates from Viresh:

  • Updated ffa driver Lei started, added memory sharing interface

  • Starting work on the interface to FFA DMA hal, tring to make it generic

  • Lorenzo may have some patches to integrate FFA indirect message support in the kernel

  • Starting to work with Bertrand’s Xen work which should allow to do any DOM to any DOM (including DOMU to DOMU)

  • No API for getting FFA messages to user space (needed on device side)

  • Need to discuss in Dublin

  • Discuss meeting timings, its getting very late for India (22:30 IST) from Nov, possible to move it two hours earlier ?

Updates from Armelle

...

Virtio-msg and OPTEE? Joakim/Sumit: need to discuss in Dublin

...

OPTEE as VM

  • Keep SOC vendor in real TZ

  • Allow SW provider to use OPTEE in a pKVM VM

  • [Joakim, Something about secure timer → Armelle uses protected storage for this, timer only needs slow update (10s)]

  • HW Crypto keeps track of key expiration

...

November 7

  • No meeting due to conflict with Linaro employee meetings

Meeting notes November 21

  • Updates from Bill

  • Updates from Edgar?

    • Setup Dom0 on x86 w/ virtio-msg in kernel connecting ARM

    • Device side on Arm w/o Xen

    • Mostly working but loosing some interrupts are lost Versal to X86

    • Performance ~= 100MB Ethernet right now

    • Versal is mapping X86 memory as normal memory non-cached

    • Should work with Domu if versal PCI device is assigned to DomU

    • Will send an email w/ code pointers today or tomorrow

    • Versal side QEMU is using uio for shared memory and RX irq (send IRQ is devmem)

  • Updates from Lei?

  • Updates from Viresh?

    • Using Bertrahm Xen patches

    • Using patches for

    • Single QEMU system level w/ Xen

    • DOM0 backend in Rust for VSOCK

    • DomU kernel is using

    • /dev/virtio read & write messages (all messages including bus messages)

    • Bertrand: bus level messages should be processed in kernel

  • Alex

  • Updates from Armelle

    • Trusty is FFA compliant

    • Including Viresh work

    • Were missing UUID support but fixing that now and hope to enumerate devices

    • All new code in Trusty is Rust

    • Testing with Host not Guest VM

  • Arnaud

    • focused on co-processor

    • First working on kernel side, with Devicetree driven flow

    • https://github.com/arnopo/linux/commits/virtio-msg/

    • Single message at a time in flat memory

    • No Zephyr code yet: maybe next week

    • Scaleable enumeration? : DT fragments but we don’t know the status

  • Updates from others?

Actions: