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

Use u32 for Vsock related buffer sizes #4788

Merged
merged 3 commits into from
Sep 24, 2024

Conversation

RiverPhillips
Copy link
Contributor

@RiverPhillips RiverPhillips commented Sep 8, 2024

Changes

Use u32 for all Vsock reletated buffers instead of usize, since the Virtio specification states that lengths of virtio-buffers fit into u32

Reason

Close #4627

License Acceptance

By submitting this pull request, I confirm that my contribution is made under
the terms of the Apache 2.0 license. For more information on following Developer
Certificate of Origin and signing off your commits, please check
CONTRIBUTING.md.

PR Checklist

  • If a specific issue led to this PR, this PR closes the issue.
  • The description of changes is clear and encompassing.
  • Any required documentation changes (code and docs) are included in this
    PR.
  • API changes follow the Runbook for Firecracker API changes.
  • User-facing changes are mentioned in CHANGELOG.md.
  • All added/changed functionality is tested.
  • New TODOs link to an issue.
  • Commits meet
    contribution quality standards.

  • This functionality cannot be added in rust-vmm.

@RiverPhillips RiverPhillips marked this pull request as ready for review September 8, 2024 07:58
@Manciukic Manciukic requested review from roypat and removed request for roypat September 11, 2024 13:21
Copy link
Contributor

@roypat roypat left a comment

Choose a reason for hiding this comment

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

Hi, thanks for picking this up! After looking at this and #4637 again, I'm starting to think that changing everything in iovec.rs to u32 might not be that good an idea after all, with how much try_into() it introduces because of usize<->u32 conversations (the main goal for this exercise of using u32 was that I was hoping we'd eliminate try_into()s).

Could you drop all changes outside of the vsock module from this PR, and do the usize<->u32 thing inside {write,read}_at_offset_from in packet.rs, without any changes in iovec.rs? It should look something like

pub fn read_at_offset_from<T: ReadVolatile + Debug>(
    &mut self,
    src: &mut T,
    offset: u32,
    count: u32,
) -> Result<u32, VsockError> {
    match self.buffer {
        VsockPacketBuffer::Tx(_) => Err(VsockError::UnwritableDescriptor),
        VsockPacketBuffer::Rx(ref mut buffer) => {
            if count
                > buffer.len()
                    .saturating_sub(VSOCK_PKT_HDR_SIZE)
                    .saturating_sub(offset)
            {
                return Err(VsockError::GuestMemoryBounds);
            }

            buffer
                .write_volatile_at(src, (offset + VSOCK_PKT_HDR_SIZE) as usize, count as usize)
                .map_err(|err| VsockError::GuestMemoryMmap(GuestMemoryError::from(err)))
                .and_then(|read| read.try_into().map_err(|_| VsockError::DescChainOverflow))
        }
    }
}

As an aside (I can't leave a comment on it), in connection.rs in line 241, you can do

diff --git a/src/vmm/src/devices/virtio/vsock/csm/connection.rs b/src/vmm/src/devices/virtio/vsock/csm/connection.rs
index 9fe744058..c1ed4eeb0 100644
--- a/src/vmm/src/devices/virtio/vsock/csm/connection.rs
+++ b/src/vmm/src/devices/virtio/vsock/csm/connection.rs
@@ -237,8 +237,7 @@ where
                         // length of the read data.
                         // Safe to unwrap because read_cnt is no more than max_len, which is bounded
                         // by self.peer_avail_credit(), a u32 internally.
-                        pkt.set_op(uapi::VSOCK_OP_RW)
-                            .set_len(u32::try_from(read_cnt).unwrap());
+                        pkt.set_op(uapi::VSOCK_OP_RW).set_len(read_cnt);
                         METRICS.rx_bytes_count.add(read_cnt as u64);
                     }
                     self.rx_cnt += Wrapping(pkt.len());

:)

src/vmm/src/devices/virtio/vsock/csm/connection.rs Outdated Show resolved Hide resolved
Copy link

codecov bot commented Sep 12, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 84.32%. Comparing base (3acf37d) to head (2983c30).
Report is 4 commits behind head on main.

Current head 2983c30 differs from pull request most recent head 0de8b13

Please upload reports for the commit 0de8b13 to get more accurate results.

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #4788   +/-   ##
=======================================
  Coverage   84.32%   84.32%           
=======================================
  Files         249      249           
  Lines       27512    27513    +1     
=======================================
+ Hits        23200    23201    +1     
  Misses       4312     4312           
Flag Coverage Δ
5.10-c5n.metal 84.55% <100.00%> (+<0.01%) ⬆️
5.10-m5n.metal 84.53% <100.00%> (-0.01%) ⬇️
5.10-m6a.metal 83.82% <100.00%> (+<0.01%) ⬆️
5.10-m6g.metal 80.90% <100.00%> (+<0.01%) ⬆️
5.10-m6i.metal 84.52% <100.00%> (-0.01%) ⬇️
5.10-m7g.metal 80.90% <100.00%> (+<0.01%) ⬆️
6.1-c5n.metal 84.55% <100.00%> (+<0.01%) ⬆️
6.1-m5n.metal 84.53% <100.00%> (+<0.01%) ⬆️
6.1-m6a.metal 83.83% <100.00%> (+<0.01%) ⬆️
6.1-m6g.metal 80.90% <100.00%> (+<0.01%) ⬆️
6.1-m6i.metal 84.52% <100.00%> (-0.02%) ⬇️
6.1-m7g.metal 80.90% <100.00%> (+<0.01%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@RiverPhillips
Copy link
Contributor Author

Sorry, I'll try and fix this, looks like I forgot the DCO and the rebase changed a bunch more commits than mine

Use u32 for all Vsock related buffers instead of usize,
the Virtio specification states that lengths of virtio-buffers
fit into a u32.

Signed-off-by: River Phillips <riverphillips1@gmail.com>
Copy link
Contributor

@roypat roypat left a comment

Choose a reason for hiding this comment

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

Thanks! Sorry for the late response, I was out most of last week. I've gone ahead and squashed your commits, everything else looks good to me!

@roypat roypat added the Status: Awaiting review Indicates that a pull request is ready to be reviewed label Sep 23, 2024
@roypat roypat merged commit d772c0f into firecracker-microvm:main Sep 24, 2024
4 of 5 checks passed
@RiverPhillips RiverPhillips deleted the vsock-u32 branch September 25, 2024 13:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Awaiting review Indicates that a pull request is ready to be reviewed
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Use u32 to describe vsock related buffer sizes
3 participants