2022-05-11 Project Stratos Sync Meeting notes

 Date

May 11, 2022

 Participants

  • @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

  •  

 Agenda

 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

16:19

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

Arnd Bergmann

16:34

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

16:39

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

You

16:41

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

Arnd Bergmann

16:58

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