There is one corner case which was not properly handled by the current
code from our AddressAllocator. If both the address start (from the
next range) and the requested region size are already aligned on the
same value as "alignment", when doing the substract of the requested
size + alignment, the returned address is already aligned. The problem
is that we might end up overlapping with an existing range since the
check between the available delta and the requested size does not take
into account a full extra alignment.
By substracting the requested size + alignment - 1 from the address
start of the next range, we ensure this kind of corner case would not
happen since the address won't be naturally aligned and after some
adjustment from the function align_address(), the correct start address
will be returned.
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
The requested address for a range can be the base of the entire
address space, this is a valid use case.
In particular, when creating an MMIO address space of 0-64GiB, we
might want to create a range of 0-1GiB if the RAM of our VM is 1G.
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
This patch fixes the function first_available_range() responsible
for finding the first range that could fit the requested size.
The algorithm was working, that is allocating ranges from the end
of the address space because we created an empty region right at the
end. But the problem is, the VMM might request for some specific
allocations at fixed address to allocate the RAM for example. In this
case, the RAM range could be 0-1GiB, which means with the previous
algorithm, the new available range would have been found right after
1GiB.
This is not the intended behavior, and that's why the algorithm has
been fixed by this patch, making sure to walk down existing ranges
starting from the end.
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
There is alignment support for AddressAllocator but there are occations
that the alignment is known only when we call allocate(). One example
is PCI BAR which is natually aligned, means for which we have to align
the base address to its size.
Signed-off-by: Chao Peng <chao.p.peng@linux.intel.com>
We can only free ranges that exactly map an already allocated one, i.e.
this is not a range resizing.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Add the BSD and Apache license.
Make all crosvm references point to the BSD license.
Add the right copyrights and identifier to our VMM code.
Add Intel copyright to the vm-virtio and pci crates.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
This is based on the crosvm resource allocator from commit 107edb3e.
We only have PIO and MMIO address space to handle, and don't have a GPU
specific path and space.
Also, we support allocating a range at a specified address. This is
mostly useful for PIO, but might be also necessary for MMIO.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
