vhost-device-can: use the same socket for send/recv

[MatiasVara]

Summary of the PR

Use the same socket for send/receive in the backend to prevent guest to receiving two copies of the message when it sends to the local CAN bus.

Fixes #925

Reported-by: Francesco Valla francesco@valla.it

Requirements

Before submitting your PR, please make sure you addressed the following
requirements:

• All commits in this PR have Signed-Off-By trailers (with
  git commit -s), and the commit message has max 60 characters for the
  summary and max 75 characters for each description line.
• All added/changed functionality has a corresponding unit/integration
  test.
• All added/changed public-facing functionality has entries in the "Upcoming
  Release" section of CHANGELOG.md (if no such section exists, please create one).
• Any newly added unsafe code is properly documented.

[MatiasVara]

When fixing this, some tests started to fail since now the opening of the socket is happening in new(). Before, those tests did not require to open a socket to work. I fixed those tests by adding a few commits together with the fix. I wonder if these tests should be fixed here or in another PR.

[MatiasVara]

To run the tests, we require a virtual can interface in the host named can0.

[stefano-garzarella]

To run the tests, we require a virtual can interface in the host named can0.

Is this something new (i.e. added here) or was there before this PR?
If it's something new, I think we need to update the rust-vmm-container image to provide that device.

[MatiasVara]

To run the tests, we require a virtual can interface in the host named can0.

Is this something new (i.e. added here) or was there before this PR? If it's something new, I think we need to update the rust-vmm-container image to provide that device.

It was in the code before but it was not being tested. The tests were done to not use a can interface. I am not sure if that was done on purpose.

[epilys]

I think we should wrap the CanFdSocket field into an enum, and add a #[cfg(test)] variant that is a mock socket.

This way we can add support in the future for classic Can sockets (i.e. not FD) which is something I wanted to do anyway.

[stefano-garzarella]

To run the tests, we require a virtual can interface in the host named can0.

Is this something new (i.e. added here) or was there before this PR? If it's something new, I think we need to update the rust-vmm-container image to provide that device.

It was in the code before but it was not being tested. The tests were done to not use a can interface. I am not sure if that was done on purpose.

Maybe to avoid updating the container image xD (I have no idea).
So can we enable some can0 stub/looback interface in the container?

[epilys]

To run the tests, we require a virtual can interface in the host named can0.

Is this something new (i.e. added here) or was there before this PR? If it's something new, I think we need to update the rust-vmm-container image to provide that device.

It was in the code before but it was not being tested. The tests were done to not use a can interface. I am not sure if that was done on purpose.

Maybe to avoid updating the container image xD (I have no idea). So can we enable some can0 stub/looback interface in the container?

If the linux images contain the vcan kernel driver yes:

sudo modprobe vcan
sudo ip link add dev vcan0 type vcan
sudo ip link set vcan0 up

[MatiasVara]

I think we should wrap the CanFdSocket field into an enum, and add a #[cfg(test)] variant that is a mock socket.

Thanks! I'll try that. I did not get it completely yet though.

[MatiasVara]

The PR has now a wider scope :(. I am OK to split if it is required. Bear in mind that I used Claude for the last commit. Claude proposed a single builder for both socket types but I ignored it for the moment.