Update vhost-user-backend to 0.11 series #461
Conversation
|
Hm... We need another virtio-vsock update as well... |
|
Hm... vsock_conn.rs tests could probably benefit from a WriteVolatile impl on Cursor. But I am not going through another round of major updates for that. Will post the patches to add it in vm-memory but then do an additional copy for the test code here. Once the vm-memory update then goes through we can drop it. |
Yep, I agree! |
|
This is ready now! The vsock tests gave me some headache and went back and forth a couple of times until I came up with this. Since the VecDequeue impls cannot be done very nicely, I am not sure how much value there is in trying to upstream them to vm-memory. The tricks that we did to make it fast for |
These Read/Write implementations always read/wrote to the start of the slice. This is a bit awkward and does not become easier by the test relying on this behaviour. Fix this by using a pair of VecDequeue, one for the read and one for the write buffer. This better mimics a pair of network sockets. This allows mocking the read/writes in a bit more natural ways. VecDeque also implements Read/Write, making our impls for those a simple forward. Signed-off-by: Erik Schilling <erik.schilling@linaro.org>
Except that it needs a rebase now... |
|
Rebased. |
|
Ah. Forgot about staging... |
|
@Ablu staging crates are still failing: https://buildkite.com/rust-vmm/vhost-device-ci/builds/1960#018bc957-95ab-48d2-bea7-00fea0939a0a |
Yes, still fixing it. forgot to bump backend, but something else is missing too. Will sort it out. |
|
Hm. Is this crash known for staging? |
|
Apart from the crash I also finished the update in staging. |
@dorindabassey @MatiasVara @epilys any idea of this? |
Those logs are about |
The executable looks like the sound one: |
- Features were renamed from slave -> backend - Generics got simplified - Some write and read functions on Volatile slice got turned into standalone traits: ReadVolatile, WriteVolatile - handle_event no longer returns a bool Signed-off-by: Erik Schilling <erik.schilling@linaro.org>
|
I can no longer reproduce the crash during tests... So I guess that can be handled separately from this. I will try to reproduce it with address sanitizers and open an issue if I can reproduce it again. |
|
Is it okay with everyone to delay merging till we test some of the devices by launching them with VMs? Just to make sure everything is ok to go. |
Sure! Though we probably have a testing gap somewhere if stuff is failing there but not in our tests. |
|
I reproduced the |
|
Thanks for reviews! @epilys: Got any specific tests in mind? Feel free to hit merge when you are happy. I am having better integration tests somewhere on my TODO list. Though I am not yet sure about the final form... We will probably develop integration tests for TRS, but those would only be able to run post-merge. Maybe it might make sense to collect ideas on a ticket? Overall, I think this is not more or less dangerous compared to any other PR. While this includes some major bumps, the actual changes are fairly "simple". |
Draft until the version is actually released
Requirements
Before submitting your PR, please make sure you addressed the following
requirements:
git commit -s), and the commitmessage has max 60 characters for the summary and max 75 characters for each
description line.
test.
Release" section of CHANGELOG.md (if no such section exists, please create one).
unsafecode is properly documented.