build(deps): update vm-memory requirement from 0.12.2 to 0.13.0

[dependabot]

Updates the requirements on vm-memory to permit the latest version.

Changelog

Sourced from vm-memory's changelog.

[v0.13.0]

Added

• [#247](rust-vmm/vm-memory#247) Add ReadVolatile and WriteVolatile traits which are equivalents of Read/Write with volatile access semantics.

Changed

• [#247](rust-vmm/vm-memory#247) Deprecate Bytes::{read_from, read_exact_from, write_to, write_all_to}. Instead use ReadVolatile/WriteVolatile, which do not incur the performance penalty of copying to hypervisor memory due to Read/Write being incompatible with volatile semantics (see also #217).

[v0.12.2]

Fixed

• [#251](rust-vmm/vm-memory#251): Inserted checks that verify that the value returned by VolatileMemory::get_slice is of the correct length.

Deprecated

• [#244](rust-vmm/vm-memory#241) Deprecate volatile memory's as_ptr() interfaces. The new interfaces to be used instead are: ptr_guard() and ptr_guard_mut().

[v0.12.1]

Fixed

• [#241](rust-vmm/vm-memory#245) mmap_xen: Don't drop the FileOffset while in use #245

[v0.12.0]

Added

• [#241](rust-vmm/vm-memory#241) Add Xen memory mapping support: Foreign and Grant. Add new API for accessing pointers to volatile slices, as as_ptr() can't be used with Xen's Grant mapping.
• [#237](rust-vmm/vm-memory#237) Implement ByteValued for i/u128.

[v0.11.0]

Added

• [#216](rust-vmm/vm-memory#216) Add GuestRegionMmap::from_region.

Fixed

• [#217](rust-vmm/vm-memory#217) Fix vm-memory internally taking rust-style slices to guest memory in ways that could potentially cause

... (truncated)

Commits

• a6bcb43 chore: Prepare release 0.13.0
• 51a6c74 Add CHANGELOG entry about ReadVolatile/WriteVolatile
• 20135ce Adjust coverage
• 7a911a4 Add read_volatile_from/write_volatile_to to GuestMemory
• 9c3e6aa test: Add tests for VolatileRead/Write
• 0173112 feat: Introduce Read/WriteVolatile traits
• See full diff in compare view

You can trigger a rebase of this PR by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[roypat]

This is blocked on rust-vmm/vm-memory#256

[stefano-garzarella]

@roypat for bisectability would it be better to merge the first 2 commits together?
IIUC the first one fails to compile right?

[roypat]

@roypat for bisectability would it be better to merge the first 2 commits together? IIUC the first one fails to compile right?

Mh, I think usually we try to keep the dependabot-created commits untouched, and add the fixes in additional commits onto the dependabot branch.

[stefano-garzarella]

@roypat for bisectability would it be better to merge the first 2 commits together? IIUC the first one fails to compile right?

Mh, I think usually we try to keep the dependabot-created commits untouched, and add the fixes in additional commits onto the dependabot branch.

Okay, sorry I'm not codeowner of this crate, so I didn't know about this policy. I personally prefer to try to have every commit buildable, but it’s up to you ;-)

[rbradford]

@roypat for bisectability would it be better to merge the first 2 commits together? IIUC the first one fails to compile right?

Mh, I think usually we try to keep the dependabot-created commits untouched, and add the fixes in additional commits onto the dependabot branch.

I don't think that sounds like a very good idea from a bisectability perspective. I don't think the dependabot's feelings will be hurt if you take it's commit and git commit --amend --reset-author and turn it into a generic dependency bump commit.

[roypat]

@roypat for bisectability would it be better to merge the first 2 commits together? IIUC the first one fails to compile right?

Mh, I think usually we try to keep the dependabot-created commits untouched, and add the fixes in additional commits onto the dependabot branch.

I don't think that sounds like a very good idea from a bisectability perspective. I don't think the dependabot's feelings will be hurt if you take it's commit and git commit --amend --reset-author and turn it into a generic dependency bump commit.

Alright, if we don't care about preserving the dependabot commits then I don't see any problems either :) I've squashed the first two commits.
To be fair, its not like it didn't compile, there were simply new compiler warnings that I don't think would cause any problems with bisection.

[epilys]

+1 on squashing dependabot's commits. You can mention it was originally an automatic dependabot PR in the commit description if you like.

[rbradford]

Alright, if we don't care about preserving the dependabot commits then I don't see any problems either :) I've squashed the first two commits.
To be fair, its not like it didn't compile, there were simply new compiler warnings that I don't think would cause any problems with bisection.

Ah, my mistake - I didn't realise it was "just a warning". I can see the merits of both ways when it comes to a warning but for build errors I do think it's better for the tree to be bisectable.