Summary of Month

Plans

• Spec:

  • Fix-up compliance conformance

  • Publish PATCHv1 to virtio-comment list

• hvac-demo updates:

  • Rebase demo-amp-qemu-pci to Edgar’s QEMU RFC

  • Rebase all/most demos to align with Spec PATCHv1

  • Add demo-ffa-optee

  • Build AMD 5050A demo from hvac-demo repo

• virtio-msg-amp:

  • Reproduce ST Linux / Zephyr demo

  • Stretch: Implement new queue format in kernel and test kernel to kernel

Meeting December 4

Viresh VSOCK DMA_BUF demo walk through

• Talked through diagram and text on page

• Lots of discussion about how the memory should be allocated and shared

• It is clear the the buffer should be allocated from a DMA_BUF heap specified by the specific virtio-msg bus in use

• Bertrand says we should be using the dma.ops that are published by the virtio-msg-xxx

• Manos points out that this should probably work for virtio-pci and -mmio as well

• Bill asked about buffer release and Viresh say he has release possible in either direction but now relises that the driver initiated release needs a complete indication from the device side.

• Note: In this model, Data is always shared from driver to device.

• (If you wanted to share memory from device to driver, it should probably use the virtio v1.3 shmem facility.)

• Viresh thinks he understands what Bertrand wants and will take a look

Edgar’s buffer sharing between Xen VMs (Prio

• https://github.com/edgarigl/dmabuf-transfer

• User space is doing the allocation and shareing

• Uses TCP to transport the “fd” handle

Bertrand’s spec work

• PR #28 is ready for review

• Compliance is done from Bertrand’s POV

• Needs more more eyeballs

• Any functional changes: PING ID?

Edgar’s changes to kernel

• Has some changes to viresh’s user space API

• Add support for poll APIs

• Refill on demand to handle N messages back to back (keep messages in HW fifo until single buffer is API code is available)

Meeting December 18

Note: Action items below in bold

Logistics:

• Agreed to cancel Jan 1 meeting

• Verified that HVAC confluence and Jira are visible (read-only) w/o Linaro log-in.

• Meting Recording and transcript: https://linaro-org.zoom.us/rec/share/vBfmLdeO2aG4voJ_08WMfoWng77TgLVSefRWZuZ-oyk-e60NjXqG2KuvaUeQqLg.UXTzRJL3N-Gl5KDW?startTime=1766069879000
  Passcode: %8*58L+M

Spec Status

• Bertrand said he did not get any new feedback on his PR. Manos said he had read it and things it is good

• Bill does not have spec patch v1 ready yet. Will get a squashed branch ready and send practice email to our mail list.

• Bill will accept PR as is; any fixup can be done based on new state.

• We all agreed that pushing it no right before holiday break would not be good. Will push in Early January.

• Alex suggested we do a LWN article about Virtio-msg. We should work on it cooperatively but we need a primary author. It was agreed that it should come from Linaro. Bill/Alex/Sumit took the action to define a primary author.

Virtio-msg at Plumbers

• Summit talked about a presentation at Plumbers and how he suggested virtio-msg might be a good solution. The area is providing services to Confidential VMs on x86 (ex: AMD SEV-SNP) by Stefano Garzarella.

• Stefano G seems pretty interested in the idea. Manos will talk to him about it. (Update (Manos): Reply was “not in the short term, kind of next year some time”)

• Bill asked about ArmCCA. Bertrand says the RMA does not support FFA as of today and they are using trap and emulate Virtio today. Virtio-msg should be applicable and an improvement.

Upstream Status for Xen and QEMU

• Bertrand shared FFA enablement status in Upstream Xen: one maintainer has looked at first series; no one objected. There are two more patch series pending before it will be complete. The new branches are not just POC; they have been tested against the FFA conformance tests and Bertrand feels they are ready. FFA support will be in the next Xen release but that is not scheduled until about September 2026

• Edgar’s QEMU RFC got good feedback from Alex but no one else yet. Edgar think he should send a new version as he has adopted they feedback from Alex and made other improvements now.

• Alex is unsure if the getting into virtio spec is required for QEMU acceptance. It at least needs to look like it will.

Virtio-msg over Virtio Admin queues

• Bill talked about virtio-msg over virtio admin queues as a way to do the use case the Intel guys were trying to do a couple of years ago (nested Virtio or Virtio for sub-devices, SRIOV etc)

• Bill to check if Admin Queues are virtio 1.3 or 1.4

• Basic Admin Queues did exist in virtio v1.3 but v1.4 greatly expanded the scope to include: capabilities, resource-objects, and device-parts

Viresh’s updates for VSOCK & OP-TEE

• Jens has made OP-TEE updates and Viresh has folded them in and made it work again

• Viresh has taken the feedback from last meeting about using the dma_ops of the device and has made updates to ensure that the dma_ops do get used.

• One issue that Viresh sees with this new model is that the sharing happens at the time of allocation. He would prefer to see it happen on first use with VSOCK.

• Viresh asked what metadata should be shared in the VSOCK data sharing meta data. Currently he has a base Bus address, size, (probably should add offset also), the share op (share, unshare, share_ack, ushare_ack, etc), and currently he has a memory type.

• Do we really need the shmem type? It would be really nice if we could eliminate the shared memory type as that would avoid having to add a new DMA_BUF.op member .

• We discussed this for quite a while looking how it could work for FF-A and Xen.

• The user space interface should be kept simple and is probably just a file handle to the DMABUF and the shmem op.

• The kernel should expand the handle (Linux local) to meta data for the VSOCK message.

• If userspace passes a handle that wont work with the virtio-msg transport, it should get an error

• There was some confusion about how this works on Xen with page grants especially a DOMU sharing pages with a DOMD (that does not have all the special powers of a DOM0).

• Bertrand will take a look at how this should work in Xen

Using Virtio level shmem for VSOCK etc

• Manos suggested that we should use Virtio level shmem for this memory sharing

• Bill sees problems as this memory always exists on the device side and is shared with the driver side. virtio-gpu and virtio-media may have in-band methods to allocate from this memory (or even set up new ones?) but this does not exist generically at the transport level.

• Manos will find/write-up examples of what he envisions and will share with the group

Note: No meeting Jan 1!