Add support for VHOST_USER_GPU_SET_SOCKET

[mtjhrc]

Summary of the PR

Me and @dorindabassey have been working on this PR, which adds support for the QEMU's vhost-user-gpu protocol.
This is a protocol for sending messeges from backend to the fronted, it is needed to implement display output in QEMU to implement a vhost-user-gpu device.
See issue #236

This feature is very similar to the SET_BACKEND_REQ_FD, so it is implemented in a similar way.
Support is only added for sending these vhost messages from backend to frontend. Support for handling this protocol on frontend is not implemented.

The protocol is very similar to the normal vhost protocol, but the valid header flags of the VhostUserMsgHeader and the newly introduced VhostUserGpuMsgHeader are different. (There is no version bit, only reply bit is specified). So the Endpoint utility was made generic over the header type, not just the request. Unfortunately there is another issue, that the messages VHOST_USER_GPU_SCANOUT and VHOST_USER_GPU_CURSOR_UPDATE are bigger than the MAX_MSG_SIZE. So we added methods for sending bigger messages to Endpoint.

vhost/vhost/src/vhost_user/message.rs

Lines 26 to 33 in bd6bf13

	/// The vhost-user specification uses a field of u32 to store message length.
	/// On the other hand, preallocated buffers are needed to receive messages from the Unix domain
	/// socket. To preallocating a 4GB buffer for each vhost-user message is really just an overhead.
	/// Among all defined vhost-user messages, only the VhostUserConfig and VhostUserMemory has variable
	/// message size. For the VhostUserConfig, a maximum size of 4K is enough because the user
	/// configuration space for virtio devices is (4K - 0x100) bytes at most. For the VhostUserMemory,
	/// 4K should be enough too because it can support 255 memory regions at most.
	pub const MAX_MSG_SIZE: usize = 0x1000;

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.

[stefano-garzarella]

I left some comments, but the code is almost fine with me.

Please fix the commit messages, some of them doesn't have any description (please also just a line describing the type of message you're adding is enough, but avoid empty), others doesn't have new lines before S-o-b.

Also check copyright and SPDX of new files.

[mtjhrc]

Apart from changes you requested I also changed the signature of cursor_update, to accept the array outside of the struct as I realized this is more practical to the user. This also meant I removed a test for sending such a big message body.

[mtjhrc]

I am not sure about the changes in regards to sending big message. I added a constant to the MsgHeader trait and use it for checking size when sending messages. I also left a TODO comment. I think we could support u32::MAX everywhere but, this warrants a separate PR and a discussion if we want to enforce the current MAX_MSG_SIZE for vhost protocol, also there are some redundant checks for this at multiple levels and I think the checks could probably overflow when adding numbers.

[stefano-garzarella]

I did a quick review and I think we are in a good shape :-)

I just suggest that you fix the description a bit in the commits. Take a look here: https://docs.kernel.org/process/submitting-patches.html

Describe your changes in imperative mood, e.g. “make xyzzy do frotz” instead of “[This patch] makes xyzzy do frotz” or “[I] changed xyzzy to do frotz”, as if you are giving orders to the codebase to change its behaviour.

[aesteve-rh]

In general LGTM, but the PR is really long, not sure if it would be better to split some of the initial commits that have fewer dependencies.

I left a few comments, and I will give it another pass for the next round.

[mtjhrc]

I changed the internal API used here like discussed here with @stefano-garzarella, this makes each message method explicitly call recv_reply (instead of wait_for_ack) if it is needed.
So instead of

pub fn get_display_info(&self) -> io::Result<VirtioGpuRespDisplayInfo> {
    self.send_header(GpuBackendReq::GET_DISPLAY_INFO, None)
}

the public methods now do:

pub fn get_display_info(&self) -> io::Result<VirtioGpuRespDisplayInfo> {
    let node = self.node(); // locks the mutex and returns a reference 
   
    let hdr = node.send_header(GpuBackendReq::GET_DISPLAY_INFO, None)?;
    node.recv_reply(&hdr)
}

Note that some messeges aren't supposed to wait for a reply so this removes the need for overly specific utility methods like send_message_with_payload_no_reply.
I also added a comment in the code explaining that there is no VHOST_USER_PROTOCOL_F_REPLY_ACK flag for this protocol. Because of this I now changed the tests to call the public methods, since more of the code moved there.

[stefano-garzarella]

@mtjhrc great! Thanks, I'll review in the next days (I'm going to DevConf at Brno, so maybe it will take a while, sorry in advance).

Since you are here, can you also rebase on the latest main?

[mtjhrc]

@mtjhrc great! Thanks, I'll review in the next days (I'm going to DevConf at Brno, so maybe it will take a while, sorry in advance).

Since you are here, can you also rebase on the latest main?

Rebased. No problem, also sorry for the delay fixing this on my side too.

[stefano-garzarella]

@mtjhrc great work about send_*() API!

The PR LGTM, but maybe during the rebase the change to enable gpu-socket in .buildkite/rust-vmm-ci-tests.json are lost. Can you check it?

[aesteve-rh]

LGTM!

[mtjhrc]

@mtjhrc great work about send_*() API!

The PR LGTM, but maybe during the rebase the change to enable gpu-socket in .buildkite/rust-vmm-ci-tests.json are lost. Can you check it?

I have fixed this and rebased the PR.

[stefano-garzarella]

@germag @slp can you take a look?