Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

vsock: Increase NUM_QUEUES to 3 #409

Merged
merged 3 commits into from
Jul 28, 2023
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 8 additions & 4 deletions crates/vsock/src/vhu_vsock.rs
Original file line number Diff line number Diff line change
Expand Up @@ -26,7 +26,7 @@ use crate::vhu_vsock_thread::*;

pub(crate) type CidMap = HashMap<u64, (Arc<RwLock<RawPktsQ>>, EventFd)>;

const NUM_QUEUES: usize = 2;
const NUM_QUEUES: usize = 3;
const QUEUE_SIZE: usize = 256;

// New descriptors pending on the rx queue
Expand All @@ -37,10 +37,12 @@ const TX_QUEUE_EVENT: u16 = 1;
const EVT_QUEUE_EVENT: u16 = 2;

/// Notification coming from the backend.
pub(crate) const BACKEND_EVENT: u16 = 3;
/// Event range [0...num_queues] is reserved for queues and exit event.
/// So NUM_QUEUES + 1 is used.
pub(crate) const BACKEND_EVENT: u16 = (NUM_QUEUES + 1) as u16;

/// Notification coming from the sibling VM.
pub(crate) const SIBLING_VM_EVENT: u16 = 4;
pub(crate) const SIBLING_VM_EVENT: u16 = BACKEND_EVENT + 1;

/// CID of the host
pub(crate) const VSOCK_HOST_CID: u64 = 2;
Expand Down Expand Up @@ -295,7 +297,9 @@ impl VhostUserBackend<VringRwLock, ()> for VhostUserVsockBackend {
TX_QUEUE_EVENT => {
thread.process_tx(vring_tx, evt_idx)?;
}
EVT_QUEUE_EVENT => {}
EVT_QUEUE_EVENT => {
warn!("Received an unexpected EVT_QUEUE_EVENT");
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is actually the device that sends events to the guest. When you get a virtqueue request from the guest, it isn't sending an event, it is just providing a buffer so that the host can send the event in the response whenever it feels the need. Keeping this as a no-op is probably more appropriate.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this device we do not support sending events to the guest, so we expect the VMM to do so (e.g. QEMU). That's why we put the warning, because it's the VMM that should intercept these events and handle the free buffers posited by the driver.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. I'd guess really want to print the message when/if the 3rd queue is supplied at all, not necessarily when you get requests from it, but this is the easiest approximation.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The third queue has to be provided to the guest in any case, but for example in QEMU, it handles it itself. So there is no expectation of receiving this event here. In crosvm this is not true?

}
BACKEND_EVENT => {
thread.process_backend_evt(evset);
if let Err(e) = thread.process_tx(vring_tx, evt_idx) {
Expand Down