rust-vmm / vm-allocator Goto Github PK

Dependabot couldn't parse the Cargo.toml found at /Cargo.toml.

The error Dependabot encountered was:

Dependabot::DependencyFileNotParseable

View the update logs.

I came across a bug which manifests when allocating with an alignment other than 0.

The problem manifests when we get a candidate range which can fit our allocation, but in order
to respect the alignment properties the allocated range starts one byte after the start of the candidate node.
In this case we try to add back an InnerNode of size 1.

This should work, but the constructor of RangeInclusive fails due to this check which is meant to check
for ranges bigger than u64::MAX + 1.

MRE:

use vm_allocator::{AddressAllocator, AllocPolicy};

fn main() {
    let mut allocator = AddressAllocator::new(1, 1000).unwrap();
    //This should return us range [2,11] 
    let addr = allocator.allocate(10, 2, AllocPolicy::FirstMatch)
    // but it will fail because internally the allocator which will try to
    // create a Node with Range [1,1] which will fail
   .unwrap();
    println!("Allocated address: {}", addr.start());
}

Above will fail with:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: InvalidRange(1, 1)', src/main.rs:9:10
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

It is very easy to misuse the Constraint interface because it has side effects. For example, the policy MUST be set before setting the alignment because otherwise the alignment check is wrong.
The Constraint is constructed as a builder, but does not implement the full pattern, which makes it easy to misuse.

This needs to be readjusted as specified in the Rust Builder Pattern documentation: https://rust-unofficial.github.io/patterns/patterns/creational/builder.html

The Range object already exists in Rust. Instead of reimplementing the functionality, we can just extend such that we can add the needed functionality, which for now is just theoverlaps function.

Also, depending on how the crate is shaped, we will need to use either Range or RangeInclusive, where the latter represents a range that is inclusive on both ends:

• https://doc.rust-lang.org/std/ops/struct.RangeInclusive.html
• https://doc.rust-lang.org/std/ops/struct.Range.html

Hi, I'm Chao 😄
I would like to initiate the discussion about the requirement and usage of vm-allocator.

The Big Picture

To start with a big picture, we think vm-allocator should be used for managing (allocating + releasing + tracking) guest resource for other components who need guest resource. vm-allocator is responsible for tracking all the resource usage and other components implements methods to access or control resources allocated from vm-allocator.

We think there are 2 main concepts needed clerification in vm-allocator design : resource and allocator

Resource

Resource should be managed by vm-allocator and let vm-allocator keep track of the resource usage.

After skimming through several VMM, resource here could be 3 kinds :

1. ID resource. e.g. PCI device id
2. Memory resource. e.g. MMIO, PIO address space
3. Interrupt resource. e.g. msi irq

We should have an allocator general enough to allocate all those kinds of resource so that we don't need a new struct for every kind of resource.

Allocator

Allocator is used to manage (allocate + release + track) the resource.
Allocator itself should have a range/pool for maximum resource to be allocated.

How to ask for the resource allocation

We think there should be a constraint for other components to ask for resource from vm-allocator.

Constraint should describe the size of the resource it wants, the lower boundary it wants for the resource from the resource pool (optional), the upper boundary(optional) and the alignment(optional)

Once components could clearly describe the constraint for the resource they need, vm-allocator could find the most appropriate resource for them.

How to ask for the resource release

Other components could give the exact resource(e.g. address space range, id number) / device name/device struct to let vm-allocator know which resource to release.

How to allocate, release and track resource

Resource Allocation should follow these rules:

1. Different allocations should not overlay with each other.
2. Resource allocations shouldn't pass the lower and upper bound.
3. Resource allocations should follow the description of the constraint

Resource Release will free the resource range from the resource pool and other allocation could use that range.

Recource Track means vm-allocator should have the ability to query for the resource.

Summary

As the conclusion, the vm-allocator would be made of one allocator for managing resource and constraint for describing the resource needed.

The public documentation should not have details about internal only structures. For example this is the case with:

We should scan all the public documentation and see what else is similar, and what we need to extend.

I was reviewing crate licenses and encountered three issues here:

• The allocation_engine files declare SPDX-License-Identifier: Apache-2, but the SPDX ID is Apache-2.0.
• Both the Cargo.toml file and README says the project is dual licensed (Apache-2.0 or BSD-3-Clause), but the crate includes multiple files that are Apache-2.0-only, e.g. src/lib.rs. Should the crate license be just Apache-2.0 and maybe mention there are some dual-licensed source files in the README?
• The BSD license text is missing. Can a file LICENSE-BSD-3-Clause be added to the crate?

Hello! Is it a good idea to use AddressAllocator with specified large chunk of executable pages to allocate memory for JIT?

there is currently no way of allocating a particular id in the IdAllocator.

We have to add:

• repository link
• readme

Check if anything else is missing.

For now we have some internal documentation and some examples in the readme.

This needs to be replaced with u64::MAX.