Versions Compared

Old Version 4

changes.mady.by.user Alex Bennée

Saved on

compared with

New Version Current

changes.mady.by.user Mike Holmes

Saved on

Key

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

Date

Participants

  • Mike

  • Alex

  • Vincent

  • Mathieu

  • Francois

  • Randy

  • Illias

  • Don

  • Jean-Philip

  • Arnd

  • Ruchika

  • Joakim

  • Trilok (QC)

  • Srivatsa()

  • Peter

  • Arnaud ()

  • Bil Mills

  • Bogdan Vlad

Agenda

Excerpt

  • Updates

  • Heads up and early questions for Illias on issues uncovered using the Trusted Subsrate work to boot Xen

  • What are the implications around virtio-ethernet interface and standard infrastructure at a host level for vm-to-vm communication where the VMs host applications that were on separate Devices.

  • virtio-gpu vs virtio-wayland

Discussion topics

  • Updates on progress

    • 1st versions damon for i2c, rng

    • Alex blocking Xen

    • Rust training before rust implementations

    • Mathieu - reviews taking a long time for QEMU, Alex has it in his queue. Vincent do we need C version in QEMU if we have a rust implementation. Alex does not hurt, hope rust is the maintained version. Arnd I2C QEMU version is very useful, vhost users cant do this. Virto-i2c backend is useful. Support did just go in for multiprocess QEMU, we could embed I2C via this. Arnd all slave would need to be moved. Arndwe have the same issue with gpio, Viresh just posted his driver. Srivatsa, we would only need it for testing? Arnd think we may need it. Alex, would then have a mini VM setup vs a full OS. Arnd use case such as ethernet packet LED blinking, getting data from DT. Alex need a way to tell.

    • Vincent SCMI backend, SCP working with Zephyr, was more complex than expected, goal scp firmware running in the guest VM and resuing the repo for the coprocessor or op-tee

  • Trusted Subsrate work to boot Xen

    • Looking at security bring up Xen with TS

    • normal Xen, and Dom0less Xen. normal Xen….

    • Using EFI

    • Dom0

      • load uboot authenticate TFA

      • uboot supports EFI

      • YOu can trust the result

      • you can sign Xen, load Xen via EFI and you are fine. Then Xen does something similar to Grub to verify extra binaries.

      • You could do this more simply, but this

      • Dom0less

        • preload kernel, dtb, initrd via uboot

        • load Xen efi knows where to find but does not authenticate

        • Every VM runs a kernel that you cant attest

        • Could put all images in fit images, and verify before Xen

        • You get VMs you can trust, but EFI loses

      • Need to make Xen EFI aware for the Trusted Substratee case, this mavirtio-gpu vs virtio-waylandkes the boot loader irrelevant

      • Alex is this code in Xen? Ilias replace with EFI callbacks to load the binary.

      • Alex would Xen be asking ….. not typing fast enough!

      • Steffano does not dislike the idea

      • Issues : EFI and Kernel have no way to authenticate …

      • BIll M dom0 cases will be static deployments

      • Bill Ledge discussion - for the UEFI objectors, uboot loads them all is a simpler thing. Illias not sure it is simpler. Ext model can work with and without EFI.

      • Bill not bought into everything in one fit, update one Dom you have to update all, might work for chromOS but not a wider usecase.

      • Onefit proposal motivated by system as ….

  • Ethernet between VMs - is there an issue ?

    • virtio-net can do anything a nic can

    • Arnd multiple ethernet to VMs needs a virtual switch

    • Dom0 or KVM could do the switch but it would see all data, probably not want to do this with type1

    • The usual way with KVM is us vhost-net and use kernels network layers, or use the nic if capable.

    • if on the same core it will be cache hot and might be quite fast, if not, if not,

    • Illias use XDP - with BPF you can redirect, Armd if you only have VMs you have to copy

    • CAN is a multidrop bus, if replicating point to point may be simpler.

    • If you need to also talk off Soc then virtual ethernet makes sense.

  • virtio-gpu vs virtio-wayland

    • Alex Virtio-wayland been talked about with chromeOS, does anyone know what the difference are

    • Peter virtio-walyand is just a connection for the display, talking to the display controller of a SoC, it can decide to use the GPU. Virtio-gpu if you want to access features from the guest

    • Alex this is not either-or, it is both, vsync would be the compositor's problem, if there is no overlay it will send it straight out.

    • Alex original question, virtio-gpu only support a limited subset of colour formats yuv vs rgb. Peter you can normally use either.

    • Bill in a multiplane system protected video is probably yuv and feed directly to HW, does wayland have the capability to describe a multiplane system and let the compositor handle it. Weston can do that, but it's not over the protocol.

    • Wayland is about describing one virtual plane

    • A protected surface has been added recently

    • Alex it was an automotive use case.

    • BIll you often have multiple displays, you only need if multiple vms write to one display.

    • Illias why multiple VMs, Alex self-driving subsystem wants to warn you vs the song you are playing

    • Cluster controller would be a safe OS

Action items

Decisions