2022-05-11 Project Stratos Sync Meeting notes


May 11, 2022


  • @Alex Bennée

  • @Mathieu Poirier

  • @Leonardo Garcia

  • Srivasta (QC)

  • @Arnd Bergmann

  • Redvajesh Munibrriah (QC)

  • @Vincent Guittot

  • @Stefano Stabellini

  • Satya Sudhir Sure (QC)

  • Trilok (QC)

  • @Randy Linnell

  • Azzedine

  • Srinivas Marakala



 Discussion topics

  • SV: QC at the beggining of thinking about virtualising CANBUS

    • would like to use a standardised approach

  • RM: part of QC and the Automotive team

    • TBC: add slides

    • 1983 - introduced by Bosch to reduce the wiring loom

    • 2012 - CAN FD (Flexible Data Rate)

    • Shared bus interface

    • 2 wire bus

    • In auto you usually have multiple CAN networks with different sets of ECUs

    • Linux driver presents a character interface

      • also SocketCAN for a socket interface

    • Messages often associated with CAN ID

      • controllers tend to be configurable to ignore/accept certain can ids

    • SocketCAN is in the kernel

      • the char device was never upstreamed (usually proprietary)

      • however the char device is used for control (specific to HW)

    • Classic CAN supports 8 bytes of data, FD move to 64 bytes giving upto around 2Mbs

    • Early CAN buffering (receiving messages before SoC fully booted)

    • Virtualisation for CAN needed for

      • multiple ECUs on a single SoC

      • single VM has master control

      • pass through has issues?

    • Options 1

      • Guest->Socket CAN->Virtio-CAN

      • virtio-can needs to pass control messages (filtering etc)

      • the can controller driver provides a SW abstraction for HW

        • however not currently upstreamed

        • would need to ensure it is valid for multiple controllers

        • filter would be a union

        • bitrate setting could conflict

        • can controller has to keep context of which id’s each VM wants

    • Option 2

      • Guest has a Virtual CAN Client

      • Uses vsock/ipc to talk to host CAN server

      • the transport is abstracted by a library the app links to

  • MP: control plane and access control for CAN needs to be solved

  • AJB: can socketcan grow a control plane

    • SS: should explore that option

  • LG: how does CAN appear

    • SS: appears as a network interface (see in ifconfig)


Dump of chat buffer:

Arnd Bergmann


socketcan was merged in 2007, the chardev stuff is propretary and never got merged

Arnd Bergmann


that sounds like a show-stopper for the host side, the host really needs to go through socketcan if the host is Linux

Arnd Bergmann


I think the main pointn here is that the virtio backend must be hardware-independent, it should just be a user process talking to the kernel via socketcan

we can always extend socketcan to have features needed for virtualization



is it just the missing control path from the socketcan interface?

Arnd Bergmann


the sr-iov concept does not require PCI, but there needs to be some hardware support to have queues that one can assign to a direct based on separate MMIO spaces and IOMMUs

  File Modified

PDF File can_virt.pdf

May 13, 2022 by Alex Bennée