[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: XEN CAN Driver
Hi,
On 06.12.21 09:31, Jonas Blixt wrote:
Hello XEN developers,
We're working on a virtualized CAN driver for XEN (PV-CAN) with the intention
to upstream the patches.
In our project we use the PV CAN driver to expose a pysical CAN interface to
domU. We use cangw in
dom0 for routing between the physical interface and the PV CAN interface.
The driver implements two rings, a tx and rx ring for sending CAN frames
between dom0 and domU.
It uses three interrupts, one for indicating to domU that there are frames to
be processed in the tx ring,
one for the other way around to indicate to dom0 that domU has transmitted a
can frame and
the third to implement flow control in domU.
We're unsure if we are using the RING_ -macros the way it's intended. For
example, before
writing to the rx ring we want to check if there is enough available space in
that ring.
This is how we currently do that:
if (abs(priv->rx_ring.sring->req_prod - priv->rx_ring.sring->req_event)
>= RING_SIZE(&priv->rx_ring)-2) {
This seems wrong but at least works. The macros we tried first
(RING_FREE_REQUESTS and RING_FULL)
does not seem to work for us and that might be an indication we're not using
the RING -macros correctly.
The backend driver has one callback for receiving can frames from the interface
in
dom0 (pvcan_tx) and one interrupt handler for receiving frames from domU
(pvcan_interrupt_rx).
The frontend driver has a similar setup.
When we are sending frames to domU we're using the RING_GET_RESPONSE macro to
allocate space
in the tx_ring and in the frontend driver(pvcan_interrupt) we're also using the
RING_GET_RESPONSE
to receive the same frame. However in the other direction we're using
RING_GET_REQUEST.
I think we needed to have this setup to get the interrupts between dom0 and
domU.
Should we use two different rings for full duplex communication or is one ring
enough? I suppose if
we only used one ring the RESPONSE/REQUEST macros make more sense, I imagine
that
the front end would always allocate and write RESPONSES and the backend would
allocate and write
REQUESTS.
Another curious thing we did to get this working is in the pvcan_interrupt_rx
(backend). When we
receive frames using the RING_GET_REQUEST we also call RING_GET_RESPONSE. This
is the result of trial and error so I can't justify it beyond: if we did not
have this the ring would stall.
Basically all answers to your questions depend on the protocol used.
Is the data being sent/received by the domU put directly onto the
rings, or is it mapped via grant mappings by dom0?
Are all the requests on the rings of the same size?
Are the single requests/responses acknowledged by the other side
(I guess "yes", as I presume this is what you are referring to as
"flow control")?
Juergen
Attachment:
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
|
