Date

11 May 2022

 Participants

List meeting participants using their @ mention names

• 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

List goals for this meeting (e.g., Set design priorities for FY19)

 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