OpenAMP virtio Subgroup Meeting Notes 2023 - OpenAMP/open-amp GitHub Wiki
This meeting covers AMP virtio with a focus on usage other than remoteproc and rp-message. This is an invite only call for people actively working on this topic. If you would like to participate please join and send a message to the system reference mailing list. https://lists.openampproject.org/mailman3/lists/openamp-system-reference.lists.openampproject.org/
The meeting cadence is every 2 weeks on Wednesdays 12:30 pm Eastern US time.
Zoom link Passcode: yNRb+k38
- Bill Mills (Linaro)
- Arnaud Pouliquen (ST)
- Dan Milea (Wind River)
- Felipe Neves (Linaro)
- Mathieu Poirier (Linaro)
- Tanmay Shal (AMD Xilinx)
- M4 has physical I2C controler w/ bus and devices
- M4 provides an I2C virtio-mmio controller device to Linux
- M4 bridges the virtual I2C to the physical bus allowing Linux to access it as well
- ST's I2C demo slide set
- Zephyr work (new branch with only I2C virtio)
- Linux kernel work (right now is mixed I2C over rpmsg AND over virtio-mmio)
- In our context, "Native" virtio is existing virtio without hypervisorless or AMP support.
- Dan has isolated the work he did for native mode and created open-amp PR#494
- Another PRs also touches the virtio transport model PR#489
- 489 and 494 need to be resolved. 489 is not yet ready for merge as it breaks compatability.
- Aranud will suggest a strategy/order for merge in the next day or two.
- Independent but also virtio PR#493
- Work is being done by Felipe Neves at Linaro
- repo is here: uLipe/zephyr-openamp-rpmsg-ivshmem
- will redo this as a PR from openamp-system-reference repo
- Demo use of ivshmem to connect two QEMU instances and use for OpenAMP test bed
- Both QEMU's are Cortex-A53 as we need pci for ivshmem
- hope to do QEMU enhancement to enable a simple memap version. That will make use with MCU QEMU instances more natural and simpler.
- Right now both QEMU's are running Zephyr
- Technique works with Linux also but not tackling that yet
- Tanmay has been working on a Zynqmp mailbox driver for Zephyr
- Dan's Zephyr branch also had something for the mailbox
- This will enable rpmsg to work on Zephyr and Tanmay will get the demos to run
- Bill will get Zephyr v3.4.0 on the zephyr-openamp-staging and Tanmay will rebase on that.
- v3.4.0 has Felipe's initial support for KV260
Zoom link Passcode: =he!RwS9
Zoom link Passcode: =.nCVmC3
Zoom link Passcode: C2Jq?7Bk
Zoom Link Passcode: VV5*%^JU
Zoom link Passcode: 2jT3$9x$
- What are the big blockers for our work?
- Review of the Work threads Bill created in the March 15 notes
- We need to support at least Virtio 1.0
- What changes do we expect
- Endian is always LE in >= 1.0
- Should we support packed mode?
- Do we need to support Virtio 1.2?
- What devices should we support / prioritize
- samples/virtio/net/DHCP
- samples/virtio/entropy
- samples/virtio/serial/shell_poll
- build with
west build -p auto -b qemu_cortex_a53 samples/virtio/XXXXX
- builds all of modules/open-amp and modules/libmetal
- uses drivers/virtio/virtio-{mmio,rng,serial,net} as glue layer
- build with
west build -p auto -b qemu_cortex_r5 samples/virtio/hvl_net_rng_reloc
Zoom link Passcode: =Xb%yU4e
- Bill Mills (Linaro)
- Dan Milea (Wind River)
- Felipe Neves (Linaro)
- no: Arnaud Pouliquen (ST), (Timezone/Daylight savings time issue)
- Call time
- Availability for F2F work at Connect
- Status of where we are
- What needs to happen to get "upstream" on the RTOS side?
- open-amp library
- libmetal library
- zephyr
- (Linux side is a different topic and not the focus right now)
- What are the "threads" and "chunks" of work?
- Goal is to have chunks of work that are self contained and can be worked independently
- The meeting is at 12:30 Eastern US time every two weeks
- US has already done daylight savings time
- So meeting is 16:30 UTC until fall
- Meeting on March 29 will be after Europe has done DST so will be "normal" time
- Dan will land at airport ~ 2PM
- Felipe will land early Tuesday morning but will be jet lagged
- Bill arrives Monday morning and will be ready to go all day Tuesday
- Arnaud will get in Monday afternoon??
- Bill & Arnaud can work on something Tuesday
- Full Virtio topics are probably best saved for hacking rooms on Wed etc
- Everything on RTOS side shown in the December's demo is in OpenAMP exp-virto branches
- libmetal, open-amp, zephyr-openamp-staging
- see below for next level of detail
- Host side is mostly in kvmtool-openamp-staging
- Not discussed in call but Bill took a look later. Se below.
- This was discussed but most of the point are captured in the work items.
- libmetal
- only patch is to directly carry the zephyr integration to make the manifest easier
- open-amp
- lots of stuff here
- Dan believes most of Arnaud's objections were on the hypervisor-less mode
- we decided it would be good to focus on the "native" virtio support first.
- This can be tested with QEMU as the virtio device provider
- zephyr-openamp-staging
- too much stuff is in here and we need to move more of it to libs
- the demo app is here also
- all this is in kvmtool-openamp-staging
- In our fork the master branch and hvl-integration are equivalent right now
- The mailbox driver for kick & notify for zynqmp is in ./user-mbox-rsld
- Dan is using petalinux kernel v5.10
- Instructions for building are here:
- kvmtool-openamp-staging has:
- 46 non-merge commits that are not in upstream
- many of these patches appear to be about running vxworks in kvm, not HVL
- newest common ancestor is 90b2d3adadf218dfc6bdfdfcefe269843360223c from Aug 10 2020
- Note: kvmtool does not appear to have release tags
- Ubuntu 22.04 apt install kvmtool reports a version of 0.20170904-1.1
- This version was done by Linaro in 2017 and has had one update in 2020
- This package is in the universe section
- Get upstream at the RTOS level
- Upstream existing virtio native support to open-amp & libmetal
- Can test with Zephyr and std QEMU A53
- Move more stuff from zephyr to open-amp
- Helps with RTOS portability and reduces Zephyr upstreaming effort
- Upstream existing virtio native support to open-amp & libmetal
- Improve the Virtio APIs to improve features
- Dan had to dumb down what he had in Zephyr in order to fit the OpenAMP APIs
- Example: zero copy net
- Improve the Virtio layer and API so that can be re-enabled
- Work on improved HVL aka Vitio-MMIO AMP mode
- Define method we think can go upstream to the OASIS virtio spec
- implement both sides in library
- Can work RTOS to RTOS with 2 QEMUs and ivshmem
- Add another OS to prove portability
- Prove OS portable by doing a bare-metal or FreeRTOS build
- Add more virtio devices
- Dan is interested in vsock
- p9fs would need to hook into vfs.
- Note: Zephyr DOES have a vfs layer: https://docs.zephyrproject.org/latest/services/file_system/index.html
- Bill likes blk
- Others include i2c, gpio, and scmi
- Add support for virtio device side aka backends
- Can focus on devices that are pretty symmetrical like console or net
- Can test RTOS to RTOS with 2 QEMUs + IVSHMEM
- Show how an external protocol can hook into the library
- Things like gpu video and sound will probably never be part of the lib
- Show how an external implementation can hook into the library
- Use something simple to start with.
- Maybe SCMI and the SCP code base?
- updated HVL demo Linux + RTOS
- update demo kernel to 6.x
- support other kicks than mailbox driver?
- show co-existence of kernel level RPMsg and virtio-MMIO