\uD83D\uDDD3 Date
\uD83D\uDC65 Participants
Srivasta (QC)
Redvajesh Munibrriah (QC)
Satya Sudhir Sure (QC)
Trilok (QC)
Azzedine
Srinivas Marakala
\uD83E\uDD45 Agenda
virtio-can (Srivista)
follow-up on actions (skipped)
\uD83D\uDDE3 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