Summary of Month

Plans

• Do a 2nd spec RFC, address all open spec issues

• Build X86 + Arm demo SW from hvac-demos

• Build and run the ST A7 Linux + M4 Zephyr virtio-i2c demo on ST HW

• Define and share AMP data structures w/ “simple layout” description

• Rebase the Dual QEMU demo to the latest baseline and contain the shared memory usage to only the single IVISHMEM card

• Build the ST HW demo from the hvac-demo repo

• Stretch: Port the ST demo to a QEMU based platform, likely one of:

  • zynqmp A53+R5

  • QEMU m3 w/ ivshmem-flat and QEMU A53 w/ ivshmem

Highlights

• A lot of progress on spec toward RFCv2

• Progress on building AMD HW demo from hvac-demo repo

Issues

• RFCv2 is not ready yet

• Slow progress on hvac-demo advances

  • Bill had to spend time in other areas (helping Yocto Project 5.2 release )

Meeting April 3, special meeting for spec review

• Discussed many items but I forgot to hit record on the meeting

• All my spec review items were captured in this email.

Meeting April 10

• We are still planning to have this meeting but many people will be on vacation this week

• Alex, Edgar, Manos, Arnaud, Dan, Sumit, Lei

• Edgar: for QEMU, after connect plan to sync with spec and can make a clean rebase branch at that time

• Side bar on functional saftey WRT xen

  • Also maybe update to Viresh’s /dev/virtio-msgN to send & receive messages

• Alex: what is the QEMU interface for what we have now on Sapphire VPR hw?

  • Edgar: uio module

    • get IRQ

    • map memory uncached to userspace (Window to x86

• Bill asked Viresh & Alex how memory mapping works in rust vhost-user

  • Alex: the frontend process configres details about ranges and methods to the device process at device startup time and then the device process does the operations as needed

    • Right now the devices bin files are built with support for Xen OR kvm but the goal is to have one bin file that can do both based on what the hypervisor specific process tells it to

  • Details: VHOST_USER_PROTOCOL_F_XEN_MMAP vhost-user feature and the :xen mmap flags: in https://qemu.readthedocs.io/en/master/interop/vhost-user.html#

• Virtio-msg sprint status

  • Confirmed for Tuesday before Connect (May 13)

  • Confirmed: Edgar, Bertrand, Bill, Alex, Viresh, Lei

  • Invited but declined: Arnaud & Dan

  • Invited but not confirmed: Armelle and others from Google

Meeting April 24

• Sprint Status

  • Confirmed for Tuesday before Connect (May 13), 9am to 5pm, Meeting room 3

  • Confirmed: Edgar, Bertrand, Bill, Alex, Viresh, Lei, Lina, Armelle

  • Still room for a couple more if anyone is interested. (In person only)

• Are there any code updates for any demos before connect?

  • New code for FFA demo? Can we do memory sharing via FFA now instead of Xen page grants?

  • Bill hopes to replace demo3 with a Linux + Zephyr demo based on Arnaud’s work

  • Do we have demo code that can show Linux to TEE (Trusty) in any form?

• RFC status

  • Do RFCv2 in next couple of weeks, don’t want for aligned implementations

  • Do next as non-rfc V1 with at least a couple of aligned implementations, probably:

    • AMP (ivshmem Linux to Linux, Zephyr to Linux, maybe AMD HW x86 + Arm)

    • FFA (VM to VM via Xen, maybe others)

• Spec review status

  • Bill has started addressing his review list in PR #19, more to come soon.

  • Items that need discussion follow:

  • VIRTIO_MSG_ERROR vs a “benign response”

    • Other transports don’t have an error message. They just give harmless data if you go beyond the limits.

    • Ex: asking for Fetaures index 6 will just give all zeros. Setting features in index 6 will just return 0

    • I think we should do the same in almost every case. We can keep the ERROR messages but they should be used for really unexpected things.

    • I would add SET_CONFIG field to declare success or not.

    • Resolution:

      • Get rid of VIRTIO_MSG_ERROR (moving existing IDs down)

      • Make all Request responses enough to know what is needed

      • Bus level error message (and or LOG message is still valid but we don’t need to specify it now)

  • Device Features vs Driver Features

    • Other transports can read the device features and set and read back the driver features

    • Our GET_FEATURES does not specify which you want to read, suggest adding a qualifier

    • SET_FEATURES reply should return the resulting (driver) features as they can be different that what was requested

    • Resolution:

      • Bill’s understanding was wrong. virtio-mmio allow reading (only) device features and setting (only) driver features. There is no readback of negociated features. If device does not like the features the driver sets it can refuse to set the FEATURES_OK bit when asked.

      • Rename VIRTIO_MSG_GET_FEATURES to *_GET_DEVICE_FEATURES and VIRTIO_MSG_SET_FEATURES to VIRTIO_SET_DRIVER_FEATURES

      • Add ending status to GET_DEVICE_STATUS as was already noted in Bill’s notes

  • I want to move EVENT_ messages to 0x80, 0x81, 0x82 0x40, 0x41, 0x42 etc

    • I want to have a bigger gap between the messages that require are response and those that don't so we can add more that do

    • I think we should do the same for BUS messages but and also use 0x40, … , That still leave >= 0x80 for implementation specific

    • (implementation may use >= 0xc0 for no repsonse messages but we wont put that in the spec. Implementation specific is implementation specific)

    • Resolution:

      • Ok but use 0x40 as now shown above

      • Mention the convention in the spec when we talk about message IDs

  • I suggest replace BUS_MSG_DEVICE_{ADDED,REMOVED} with BUS_MSG_EVENT_DEVICE and that it contain a field that specified added, removed, and allow future expansion

    • Since these are EVENT like messages, name them as such

    • Resolution: none, did not get to this one

      • Bill will make a patch and include it toward the end of his PR and we can discuss it there.