In upcoming patches there will be need for allocating unique free GPE,
therefore extend system allocator appropriately.
BUG=None
TEST=Build and run crosvm with WIP patches using GPE allocator.
Additionally trigger simple, introduced test.
Change-Id: I2f175d4da58e4cba8e6a869cee537802ed197e3c
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4186656
Auto-Submit: Grzegorz Jaszczyk <jaszczyk@google.com>
Commit-Queue: Grzegorz Jaszczyk <jaszczyk@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Dmytro Maluka <dmaluka@google.com>
These should be written as ChromeOS and ChromiumOS (without the space)
to match the updated branding. The copyright headers were already
migrated to the new style (https://crrev.com/c/3894243), but there were
some more instances left over.
BUG=None
TEST=tools/cargo-doc
Change-Id: I8c76aea2eb33b2e370ab71ee9b5cc0a4cfd00585
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4129934
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
We will deserialize AddressRange from RunConfig, so make sure we error
on invalid parameters.
BUG=None
TEST=./tools/health-check
Change-Id: Ia4b5c62e61f3e12e40f400e199fc401773dbbdcc
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3970365
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
This search/replace updates all copyright notices to drop the
"All rights reserved", Use "ChromiumOS" instead of "Chromium OS"
and drops the trailing dots.
This fulfills the request from legal and unifies our notices.
./tools/health-check has been updated to only accept this style.
BUG=b:246579983
TEST=./tools/health-check
Change-Id: I87a80701dc651f1baf4820e5cc42469d7c5f5bf7
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3894243
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Replace AddressAllocator's linear search when coalescing free regions
with a search that takes advantage of the fact that the underlying
BTreeSet is sorted.
BUG=None
TEST=unit tests
TEST=boot ARCVM
TEST=boot ManaTEE and sibling crostini
Change-Id: I912ca229132780e19a05d399ac571fc6d82d1517
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3802639
Tested-by: David Stevens <stevensd@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: David Stevens <stevensd@chromium.org>
There is nothing inherently wrong with a pool that contains no space.
This will allow us to effectively remove the high MMIO region when
requested without adding Options everywhere.
BUG=b:178000549
TEST=cargo test -p resources
Change-Id: Idae3dc7e0109a6f77484576a3060f5a8a454b2c1
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3790033
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: David Stevens <stevensd@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
This allows SystemAllocator users to specify the properties of the
allocation they want rather than explicitly picking between
MmioType::Low and MmioType::High. That way, we can rearrange the
location of the prefetchable/cacheable MMIO region to accomodate use
cases like running 32-bit guest kernels without adjusting all allocation
call sites.
BUG=b:178000549
TEST=Boot x86_64 Linux in crosvm
Change-Id: I691393202c9841f4c687be55a9404fe619790634
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3784342
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: David Stevens <stevensd@chromium.org>
Add support for SHMEM_MAP and SHMEM_UNMAP. This requires mapping the
buffer in the device backend via VFIO and reconstituting it as a udmabuf
in the proxy device. It's also necessary to handle unmap operations in
the device backend, to unmap the buffer.
BUG=b:201745804
TEST=launch sibling VM on manatee
Change-Id: I505960cd5047ded172c25748c8aff32ac2d93cd7
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3779086
Tested-by: David Stevens <stevensd@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: David Stevens <stevensd@chromium.org>
crosvm is switching the import style to use one import per line.
While more verbose, this will greatly reduce the occurence of merge
conflicts going forward.
Note: This is using a nightly feature of rustfmt. So it's a one-off
re-format only. We are considering adding a nightly toolchain to
enable the feature permanently.
BUG=b:239937122
TEST=CQ
Change-Id: Id2dd4dbdc0adfc4f8f3dd1d09da1daafa2a39992
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3784345
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Manually implement Debug for AddressRange so that it gives the same
formatted output as Display.
BUG=None
TEST=compiles
Change-Id: I0d76c9aeea3c0eaac2b1c315017a14fd09d8bcd7
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3737404
Commit-Queue: David Stevens <stevensd@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Windows serializes/deserializes these types to send over a Tube.
BUG=b:213146388
TEST=built on downstream windows and presubmit
Change-Id: Ib9ca4cbb2758a997788c4bab46d573a532e8e3d4
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3735635
Commit-Queue: Vikram Auradkar <auradkar@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
The AddressRange type is used for representing contiguous memory or I/O
address ranges, mostly equivalent to RangeInclusive<u64> but with the
added benefit of implementing Copy and not carrying an extra field used
only for iteration, which we don't need.
Using an inclusive range means we can represent the full address space
with no weird corner cases around the upper limit of the range (for
example, an AddressRange covering the full 64-bit space can be
represented as start: 0, end: u64::MAX).
AddressRange also replaces the previous MemRegion type, which was a
start/size pair.
This normalizes the interface of the resources crates to use
AddressRange rather than a start/size pair; more cleanups throughout the
tree may be possible, but this commit attempts to be somewhat smaller to
have a hope of being reviewable.
BUG=b:222769529
TEST=tools/presubmit --all
TEST=cargo test -p resources
Change-Id: I8c90bdc28456221b5107ef7e589233315ea739c3
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3696671
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
Reviewed-by: David Stevens <stevensd@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Previous pcie cfg mmio is predefined as constand to avoid conflict with pci mmio,
this has two issues:
a. The size of pcie cfg mmio is limited to 64MB, so the max pci bus number is 64.
This isn't ennough for vfio-pci device, as such device's bus number is same as
host bus number, it may be above 64.
b. In manatee, CrOS may be required to have the same pcie cfg mmio base and size
as host.
So this commit add a parameter and let user could specify pcie cfg mmio base and
size. Then the guest memory layout will be adjusted to avoid conflict between
guest ram and pci low mmio.
BUG=b:197877871
TEST=run crosvm with --pcie-ecam=xxxx,xxxx, check vm's memory layout and pcie
ECAM function
Change-Id: I22cf7e2b3f01ab3f48dff9f5246cb1c24faa9703
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3305948
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Some mmio should be reserved from mmio allocator such as direct mmio and pcie config mmio,
and the space of mmio allocator is determined by arch and mmio-address-range parameter
which are in different model, it is hard to exclude the reserved mmio at mmio allocator
creation.
So this commit add a reserve_mmio() function, so that different model could call it.
If any part of the reserved mmio has been allocated, it returns Error, the caller
should handler it.
BUG=b:197877871
TEST=tools/presubmit
Change-Id: If64542ee0cef7b8949e4bd01d27f6119aea4eea0
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3605162
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Previously the iova_max_addr was got according to the cpu physical
address size. Since the cpu physical address is no more than the maximum
iova size provided by hardware iommu, the iova space size can work for
any passthrough devices. But it may not utilize the whole iova space, as
the iova size isn't got from the underlying hardware iommu.
This patch introduces a way to get iova_max_addr according to the iommu
ranges' info, therefore the iova_max_addr can be precisely calculated.
BUG=b:185084350
TEST=Boot a crosvm guest with vIOMMU enabled
Change-Id: I4ed37bf158208d61663a4bf474549df4fce3adf5
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3580373
Reviewed-by: David Stevens <stevensd@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: David Stevens <stevensd@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Make vvu use devices use VFIO to manage their virt queues. This
alleviates the need to use noiommu mode. However, it is still necessary
to use `vfio_iommu_type1.allow_unsafe_interrupts=1`.
BUG=b:202151642,b:215310597
TEST=launch sibling with vvu + virtio-iommu
Cq-Depend: chromium:3565728, chromium:3565260
Change-Id: If418524598c40a37d41c0ffaa1dcc0f8ee11fcb3
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3501052
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: David Stevens <stevensd@chromium.org>
Linux expects that PCI bars lie within a compatible bridge window, which
are typically specified via _CRS objects in ACPI. This change adds an
option to restrict mmio allocations (i.e. PCI bars) to within a
specified set of ranges. The specified set of ranges is intersected with
the default mmio allocation ranges generated by the crosvm arch code to
produce the final mmio allocation ranges.
This change is required to remove pci=nocrs from the CrOS guest's kernel
command line flags. Removing that flag is a prerequisite for enabling
virtio-iommu, since without the configuration information from ACPI, the
kernel reserves all IOVAs in iova_reserve_pci_windows.
BUG=b:181736020
TEST=boot manatee w/o pci=nocrs kernel cmdline flag
TEST=tast run trogdor|hatch arc.Boot.vm
Change-Id: I0a096420c5d5ef56dd76021951968e264ce40f42
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3499900
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: David Stevens <stevensd@chromium.org>
Add a method to SystemAllocator that returns a vector of all pools and
use it to generate the PCI ranges in build_vm. This also fixes a bug
where x86 used the size as the end address for the high_mmio region.
BUG=b:181736020
TEST=tast run trogdor|hatch arc.Boot.vm
Change-Id: Id4a300ec61c15bc08fb069b80428b22461ca935b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3516668
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: David Stevens <stevensd@chromium.org>
Remove the ramoops region from high_mmio when constructing the system
allocator. This means the aarch64 code no longer needs to manually
adjust high_mmio when determining the pci regions.
BUG=b:181736020
TEST=Check arcvm pstore still works
Change-Id: I81ca398a1984f0efb30c0a4d4b620bd50fe9df85
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3516667
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: David Stevens <stevensd@chromium.org>
Use RangeInclusive when constructing an AddressAllocator. A followup
change will add an iterator constructor, so using RangeInclusive makes
that API cleaner.
BUG=b:181736020
TEST=cargo test
Change-Id: I59c28b9cbd06c86482c0c57704fc2753a7886ac6
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3516666
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: David Stevens <stevensd@chromium.org>
Have the arch code return the SystemAllocatorConfig instead of a
SystemAllocator. This will be used to allow the core code to apply
additional restrictions on top of the arch code's restrictions.
BUG=b:181736020
TEST=compiles
Change-Id: I4d9ca277f039586e664648492c8744967dcd2ee5
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3516665
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: David Stevens <stevensd@chromium.org>
If AddressAllocator::allocate_at() fails, check if there is an existing
overlapping allocation and return it with Error::ExistingAlloc if so;
otherwise, return Error::OutOfSpace as before. This allows the caller to
distinguish between failure due to overlap and failure due to a range
that is not managed by the allocator at all.
BUG=b:188011323
TEST=cargo test -p resources
Change-Id: I1f6cde63a995dc461db221c509f4d0a1f0c7f186
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3498208
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
This reverts commit d2d66bc0a4.
Reason for revert: It turns out that adding the first page to the pool
of memory managed by the MMIO allocator has undesired consequences
since crosvm will actually use it for MMIO regions. The first page
has special semantics in other code though, and thus we get stray
accesses to this region, with hard-to-predict consequences.
BUG=b:188011323
TEST=cq
Original change's description:
> system_allocator: allow more than one region to be in the pool
>
> Allows crosvm-direct to have 0-0xfff regions to be mapped.
>
> limitations: Only the first regions gets reflected in the
> pool_base/pool_size.
>
> BUG=b:188011323
> BUG=b:184815519
> TEST=build
>
> Change-Id: I9da3cb2b8d5611068f9323d6ebf62f44162838b4
> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3450017
> Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
> Tested-by: kokoro <noreply+kokoro@google.com>
> Commit-Queue: Junichi Uekawa <uekawa@chromium.org>
Bug: b:188011323
Bug: b:184815519
Change-Id: Ib42b3007662a7a49ad876b83a01f1bb88d09d5f7
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3497136
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Mattias Nissler <mnissler@chromium.org>
Commit-Queue: Mattias Nissler <mnissler@chromium.org>
Make VfioMsixAllocator a generic resource allocator.
BUG=b:185084350
TEST=boot Linux kernel and check dmesg
Change-Id: I4a301d6829600a90fe0ddef4ccccbd4c8f511208
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3166887
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Run tests for sys_util_core, poll_token_derive and balloon_control on
windows.
Using dotfiles to disable/serialize test runs of a subset of crates does
not work well with third party crates as it forces us to commit the dot
file to the crate.
The patch modifies and uses the script that runs linux tests.
This patch also allows us to
- build/test child crate even if parent crate has disabled build/test.
- avoid building crosvm if it is not explicitly specified.
RIP short lived .windows_build_test_skip. You allowed us to run noop
kokoro tests.
Test: py .\tools\impl\test_runner.py --arch x86_64
Bug: b:215610772
Change-Id: Icc6d04ffd7c0c33d4f60aeac16fc7d23881c387d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3459809
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Vikram Auradkar <auradkar@google.com>
io ports is a 16 bit thing, check that it is actually 16 bits and fix
the parameters.
BUG=None
TEST=read intel SDM, run crosvm test
Change-Id: I50b6d5593b0699317ac2f852836208a46240714b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3470601
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Junichi Uekawa <uekawa@chromium.org>
Some tests had unrealistic values, fix them in case I want to add some
validation in the future.
BUG=None
TEST=None
Change-Id: I126c83b4ac91442f87aae8be9e84565a7a3d98a2
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3446980
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Noah Gold <nkgold@google.com>
Commit-Queue: Junichi Uekawa <uekawa@chromium.org>
Allows crosvm-direct to have 0-0xfff regions to be mapped.
limitations: Only the first regions gets reflected in the
pool_base/pool_size.
BUG=b:188011323
BUG=b:184815519
TEST=build
Change-Id: I9da3cb2b8d5611068f9323d6ebf62f44162838b4
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3450017
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Junichi Uekawa <uekawa@chromium.org>
In preparation to allow multiple low memory regions to be passed on, I wanted to
make initialization simpler.
Introduce `MemRegion` struct instead of tuple to help me understand it is a base
and size.
BUG=b:188011323
TEST=build
Change-Id: Ie8b54354a25c478d5ad0a0185b7e07d28840dd87
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3439666
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Junichi Uekawa <uekawa@chromium.org>
While reading code, some of the comments need fixing.
BUG=None
TEST=None
Change-Id: Iff9cd639f5e14512680475bcf9240c07551690a5
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3418634
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Junichi Uekawa <uekawa@chromium.org>
The patch also adds files to skip building and testing crates on
windows. When we run
```
tools/windows/build_test.py --skip_file_name .windows_build_test_skip
```
the build/test succeeds without actually doing anything as build/test
for all crates is skipped by creating '.windows_build_test_skip'.
Bug: 213170957
Test: Ran script on downstream repo
Change-Id: Iebd2cea463ee722be4feaed88229e1fb5e9fd6c5
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3417918
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Vikram Auradkar <auradkar@google.com>
This is a generalization of the existing --direct-mmio option with the
following improvements:
* Memory is mapped directly into the guest namespace rather than
handled via MMIO exits.
* The --file-backed-mapping option can be specified multiple times to
set up mappings backed by different files.
* Command line option format is extensible, allowing to add further
parameters in the future as needed.
* O_SYNC mapping is configurable from the command line, making this
useful for mapping both MMIO regions and regular system memory into
the VM.
One limitation that this new implementation brings is that mappings
need to be page-aligned (which isn't the case for --direct-mmio). I'm
not aware of existing users that require fine-granular file-backed
MMIO mappings though, so this is hopefully OK.
The existing --direct-mmio option code is left untouched, but will be
removed later after converting over existing usage.
BUG=b:184815519, b:188011323
TEST=unit tests for command line parsing, manual test to specify --file-backed-mapping and observe that the backing file content is accessible from the guest.
Change-Id: I86aee74d2032caaf9130569203d5749994a4413d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3328602
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Mattias Nissler <mnissler@chromium.org>
When allocating PCI addresses, prefer to allocate at the device
granularity (e.g. 00:01.0, 00:02.0, 00:03.0, etc.), but when these are
all allocated, start using functions (e.g. 00:01.1, 00:01.2, 00:01.3).
This enables us to add more PCI devices (31 x 8 instead of just 31)
while maintaining the existing PCI address allocation order for setups
that do not require many devices.
BUG=b:210795995
TEST=boot Linux with 32+ virtio-pci devices
Change-Id: Ic06d3c9939dd78061a51e49b4f7ec457c81c7621
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3343182
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Rather than calling get_high_mmio_base_size() twice, once in the Arch
create_system_allocator() callback and once in build_vm(), it would be
cleaner to retrieve the MMIO regions from the existing system allocator.
Add a couple of helper functions to AddressAllocator so we can get the
original region back.
This also helps in the next patch, which will pass additional
information to get_high_mmio_base_size() that is messy to calculate
twice.
BUG=b:210727578
TEST=Boot crosvm on trogdor64
Change-Id: Ia5c7d7c7ff7edb406a9b4af482b277204f865474
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3373450
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Device gets irq_num from system_allocator when device is added, this
irq_num should return to system_allocator when device is hotplug removed.
this commit adds a ReleseOneIrq interface into VmIrqRequest, it release
one gsi into system_allocator. So vfio-pci device could call it at device
close function.
For msi and msix interrupt vectors, they have irq tube already and could
call ReleaseOneIrq easily.
For legacy INTx, the gsi for vfio-pci's INTx is gotten from host, and this
gsi maybe share with other device, so the commit doesn't release this gsi
at vfio-pci device's remove, otherwise the gsi shared device will be broken.
BUG=b:185084350
TEST=Boot a guest and hotplug vfio pci device repeatedly
Change-Id: Ibcca226b4b5b2092b5bc94bef8219eea82979086
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2955580
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
For bridge's memroy and prefetch memory window, current the limit is
smaller than the base, this means pcie rp doesn't support this window,
but OS still allocates 2M memroy window and 2M prefetch memory window
for it, this has two problems:
a. kernel allocates mmio, but crosvm's system allocator doesn't capture
this allocation and crosvm still use system allocator to allocate mmio
for hotplug in device, so it may have conflict between kernel and crosvm.
b. the 2MB window is too small, as the added device behind this bridge
is allocated mmio from this window by kernel, if device required mmio
is large than 2MB, the device couldn't work.
This commit preallocates 8MB memory window and 64MB prefetch memory window
for one pcie rp, and let kernel allocate mmio for its children devices
from this window, kernel also maintains the allocation and free of this
window, crosvm system allocator doesn't care about which device own the
segment of this window.
BUG=b:185084350
TEST=Boot a guest and check pcie rp bridge window's base, limit and size
Change-Id: I566a2d81b458da1d2d5f07b689fa898453586adc
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3319706
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Each vfio pci device has a pci address, in order to support vfio
pci device hotplug repeatedly, its pci address should be returned
to system, so it could be hotplug in the next time.
BUG=b:185084350
TEST=Boot a guest and hotplug vfio pci device repeatedly
Change-Id: I0daf5bae9695c4ac87ac09581b80b69048538c0e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2955578
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
When pci bridige is created, caller should specify its primary bus
number and secondary bus number. And supposing kernel won't modify
them as the current pci device topology is simple enough, once
guest modify them, warn message will be printed.
The secondary bus number shouldn't be assigned to any other device,
so this patch loop the bus number to find a free bus number.
BUG=b:185084350
TEST=Boot a vm with passthrough device and check its function
Change-Id: Iae72a0e0401a6e75c62582456b92792a1a36211a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2955569
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Original reason for revert: Causes crosvm to not start on AMD based devices b/204222491
Fixed by clamping the maximum physical address to 64 TiB, which is the
largest physical address supported by x86-64 Linux with only 4-level
page tables enabled.
In addition, the high MMIO region size calculation has been split into a
separate function, get_high_mmio_size(), and an off-by-one error in the
size calculation was fixed.
Original change's description:
> Devices: Allocate non pci bar mmio at top of HighMmio
>
> Some devices like virtio-pmem, intel host bridge need private mmio, these private
> mmio isn't exposed to Vm through pci bar, and crosvm use mmio allocation interface
> to allocate them, so guest OS pci bus driver couldn't detect them, and once guest
> OS reallocate pci mmio, these private mmmio could be assigned to pci device bar.
> then resource conflict happens.
>
> This patch allocates these non pci bar mmio at the top of HighMmio, since HighMmio
> is large enough and OS allocates pci mmio from low to high. So these non pci bar
> mmio won't conflict with pci bar.
>
> BUG=b:199442120
> BUG=b:185084350
> TEST=crosvm run --pmem-device xxxx
>
> Change-Id: I615d7901d595dd46ba6362f88b71d96baa9c4c8f
> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3184549
> Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
> Tested-by: kokoro <noreply+kokoro@google.com>
> Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
This is a reland of https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3184549
BUG=b:199442120
BUG=b:185084350
TEST=Crostini starts on grunt (AMD device)
TEST=crosvm run --pmem-device rootfs -p 'root=/dev/pmem0' kernel
Change-Id: I7c93f7132dbfbc3f38ecbfa0504b59214a1eb6bf
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3251788
Reviewed-by: Xiong Zhang <xiong.y.zhang@intel.corp-partner.google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
This change contains the results of running
./tools/contib/cargo_refactor.py
This will break the next uprev, and needs to be synchronizized
with the corresponding ebuild changes in https://crrev.com/c/3248925
BUG=b:195126527
TEST=./tools/run_tests
Change-Id: Ied15a1841887bb8f59fba65b912b81acf69beb73
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3248129
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
This reverts commit 9557588786.
Reason for revert: Causes crosvm to not start on AMD based devices b/204222491
Original change's description:
> Devices: Allocate non pci bar mmio at top of HighMmio
>
> Some devices like virtio-pmem, intel host bridge need private mmio, these private
> mmio isn't exposed to Vm through pci bar, and crosvm use mmio allocation interface
> to allocate them, so guest OS pci bus driver couldn't detect them, and once guest
> OS reallocate pci mmio, these private mmmio could be assigned to pci device bar.
> then resource conflict happens.
>
> This patch allocates these non pci bar mmio at the top of HighMmio, since HighMmio
> is large enough and OS allocates pci mmio from low to high. So these non pci bar
> mmio won't conflict with pci bar.
>
> BUG=b:199442120
> BUG=b:185084350
> TEST=crosvm run --pmem-device xxxx
>
> Change-Id: I615d7901d595dd46ba6362f88b71d96baa9c4c8f
> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3184549
> Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
> Tested-by: kokoro <noreply+kokoro@google.com>
> Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Bug: b:199442120
Bug: b:185084350
Change-Id: Ida1369bf0b70782633b1073ceef50e1bab108f55
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3248906
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Some devices like virtio-pmem, intel host bridge need private mmio, these private
mmio isn't exposed to Vm through pci bar, and crosvm use mmio allocation interface
to allocate them, so guest OS pci bus driver couldn't detect them, and once guest
OS reallocate pci mmio, these private mmmio could be assigned to pci device bar.
then resource conflict happens.
This patch allocates these non pci bar mmio at the top of HighMmio, since HighMmio
is large enough and OS allocates pci mmio from low to high. So these non pci bar
mmio won't conflict with pci bar.
BUG=b:199442120
BUG=b:185084350
TEST=crosvm run --pmem-device xxxx
Change-Id: I615d7901d595dd46ba6362f88b71d96baa9c4c8f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3184549
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
DT platform bus abstraction requires its own MMIO address range.
Let it allocate from well defined address range.
BUG=b:185504618
TEST=trogdor64-manatee SDHCI and GENIQUP device passthrough boots/works
Change-Id: I357e909433a565968a7f081c727a3b1e420e7729
Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2961212
Commit-Queue: Micah Morton <mortonm@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Pci BusNumber is allocated by guest kernel, the BusNumber should be 0
for all the integrated pci devices and vfio-pci device, but pci bridge
and vfio-pcie device may have BusNumber > 0, so caller should know its
device BusNumber and pass it into allocate_pci() and get the desired
PciAddress.
BUG=b:185084350
TEST=None
Change-Id: I3cb18212e6c168c047f655a5f425abdeccbaae55
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2954678
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
