Uploaded image for project: 'Stratos'
  1. Stratos
  2. STR-9

Implement Optimized VirtIO interfaces

    XMLWordPrintable

    Details

    • Type: Initiative
    • Status: In Progress
    • Priority: Undecided
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      Rationale

      • This Issue developed from TSC discussion https://projects.linaro.org/browse/LBI-24 Xen for embedded / automotive
      • Virtualization has become interesting in non traditional markets, those markets are nuanced and there are some similarities across markets
        • non traditional markets are, Automotive, Cellphone, IoT
        • traditional are servers
      • Fixed phones have become platforms to run potentially millions of different apps
      • SoCs provide  cameras, modems, GPU, GPS etc and all the apps have to share the HW
      • These non traditional markets lack a defacto standard
      • Automotive Virtual Platform Specification from GENIVI describes use cases and requirements for some devices

      Scope

      • Enable front-end and back-end drivers abstractions for SoC devices in Linux
        • Specify and standardise virtio device in virtio spec
        • Write a front-end driver (for linux?)
        • Write a back-end (focusing on vhost-user with existing Hyp/VMMs)
      • Adding support for minimising the memory footprint between guest and virtio-backend
      • Performance optimisation

      Out of Scope

      • testing with non-core competency platforms such AOSP, development of  Xen, Cuttlefish or other specific hypervisors without member support
      • Implementing emulation drivers in the hypervisor

      High Level Deliverables

      • Leverage standard and emerging existing VirtIO solution when possible
      • Demonstrate working virtio backend with minimal memory view of guest
      • Deliverables are to be added as sub cards, phase one should include
        • virtio-rpmb (not limited to but also for OPTEE use in the context of a VM - required for EBBR compliant UEFI Secure Booting)
        • virtio-watchdog (to implement UEFI watchdogs in the context of EBBR compliant booting)
        • virtio-audio
      • Additional phases (not first cycle):
        • Mediated Bus Virtio (Candidates USB, SPI, I2C)
        • Complex VirtIO devices
          • Clock, PMU, GPU, Regulators

      Staffing

      • minimum one full time virtualisation engineer

      Target Platforms

      • List the architecture/board/HW IP needed to do this work
      • Simplest would be QEMU -M virt platform with PCIe discovery (TBD)

      Risks and Assumptions (keep it updated as you learn more)

      • List Risks - mitigation
        • Availability of a platform that supports the required features
      • List assumption
        • Some devices already being proposed by community - work with were appropriate
        • Other teams will use the interfaces in tight collaboration to solve real use cases such as AOSP
        • Members will be in a position to discuss and use the interfaces in a continuous interaction based on their SoCs and use cases

      Closeout Criteria

      This initiative will end when all the interfaces defined are complete
       

        Attachments

          Issue Links

            Structure

              People

              Assignee:
              alex.bennee@linaro.org Alex Bennée
              Reporter:
              mike.holmes@linaro.org Mike Holmes
              Votes:
              1 Vote for this issue
              Watchers:
              18 Start watching this issue

                Dates

                Created:
                Updated:
                Review Date: