For nonroot vfio-pci device, its prefetchable bars will be allocated
in continuous region, its nonprefetchable bars will be allocated in
another continuous region. Without descending the bar's size, this
allocation waste some mmio.
For example, a vfio-pci device has two non prefetchable bars:
bar0's size is 1M, bar2's size is 8M.
without descending [bar0, bar2], it will allocate 16M mmio, 0~8M
for Bar0, 8~16M for Bar2, although bar0 need 1M only, it occupy 8M
to satisfy bar2's 8M alignment requirement.
With descending [bar2, bar0], it will allocate 9M mmio, 0~8M for
bar2, 8M ~ 9M for bar0.
BUG=b:185084350
TEST=check pcie rp's bridge window in brya-manatee.
Change-Id: I7d93e601f6a46cabe8896aaec065a9dba18c60fa
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3500060
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Bridge window's mmio alignment went wrong during our refactor, fix
it in this commit.
BUG=b:185084350
TEST=Check bridge window and pci device mmio setting in CrOS
Change-Id: Ia1a01d1740f943ec7aa36812defe3aabffcfcbde
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3498219
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
On manatee, a vfio-pci could hotplug into an empty pcie rp when
device's host bus number is in pcie rp's bus range.
But on non-manatee, only one virtual pcie rp is created for device
hot plug, it owns one free bus number only, if a vfio-pci device's
host bus number isn't equal to rp owned bus number, this vfio-pci
device couldn't be added into guest through hotplug, so this commit
change is_match() and allow vfio-pci hotplug onto any empty pcie rp.
BUG=b:185084350
TEST=hot plug in/out a vfio-pci device with host bus_number different from
RP's bus range repeatedly in non-manatee.
Change-Id: I9a1059edd9558683e03d85235e0d164b2aa23672
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3498218
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
This snuck through as our builders were temporarily not checking
clippy in presubmit. See https://crrev.com/c/3498847
BUG=None
TEST=./tools/clippy
Change-Id: I38ca27728ab4e108539407f5499484c2b881dc47
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3499740
Auto-Submit: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Anton Romanov <romanton@google.com>
Commit-Queue: Anton Romanov <romanton@google.com>
Add a flag to the adjust command that allows the command to fail. When
this flag is set, a reply is sent with the balloon size at the end of
adjustment.
The flag also changes the semantics of inflation somewhat. By default,
the balloon driver will indefinitely retry if it fails to allocate pages
during inflation. When the flag is set, the device reacts to puff
failure notifications on the event queue by setting the target num_pages
to the current balloon size, to abort and fail the inflation attempt.
BUG=b:213962590
TEST=manual testing with crrev.com/c/3394436
TEST=check ARCVM balloon still works
Change-Id: Idd606b90550c544ce5bea085f62ac35979679d71
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3394442
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: David Stevens <stevensd@chromium.org>
Manatee doesn't support the guest accessing pages in the balloon, since
that would violate the strict its strict memory accounting, so add an
option to skip setting the deflate-on-oom flag.
However, without deflate-on-oom, the Linux driver normally modifies
MemTotal when inflating/deflating the balloon. To avoid that, this
change adds support for the new responsive-device flag proposed in [1].
[1] https://lists.oasis-open.org/archives/virtio-comment/202201/msg00139.html
BUG=b:214864326
TEST=check ARCVM balloon still works
TEST=manual testing with crrev.com/c/3394436
Change-Id: Iabc8352ee30e1b4a240fa3cad8f3b48ba53699a0
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3471335
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: David Stevens <stevensd@chromium.org>
Implement event queue that was recently proposed upstream [1]. The puff
failure event will be used in a followup CL. The pressure event is
currently ignored. Figuring out how to use it will be done later.
[1] https://lists.oasis-open.org/archives/virtio-comment/202201/msg00139.html
BUG=b:213962590,b:216214118
TEST=check ARCVM balloon still works
Change-Id: Ie1990505da8eda1358f10f24ca3c2b6196303184
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3471334
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: David Stevens <stevensd@chromium.org>
The compiler was warning about a missing `dyn` on the impl block for
PciDevice, which only contained supports_iommu():
warning: trait objects without an explicit `dyn` are deprecated
We could add the `dyn` to fix it, but it seems cleaner to just move the
definition into the VirtioPciDevice impl's existing supports_iommu
function.
Additionally fix up a few clippy warnings about open-coded instances of
map and unnecessary references.
BUG=None
TEST=cargo build # completes without warnings
TEST=tools/presubmit
Fixes: 055b81b295 ("VIRTIO_F_ACCESS_PLATFORM support in virtio-iommu")
Change-Id: I7c923d1663d4f8c958a3c79619a06ab04e1e00ae
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3498843
Reviewed-by: Anton Romanov <romanton@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
A guest VM that is launched with this new option has privileges to
manage some host system resources, for example to get involved with
host power management.
BUG=b:199383670
TEST=start crosvm with and without --privileged-vm option
Change-Id: I8c36f608458047b4189ce5eed6ea527f58fea88d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3414634
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
These may be used by the pVM firmware or bootloader for protected VMs on
Android to indicate the reason why a VM failed to boot, such as a
verification failure, and so we want to have them in the logs for
debugging.
BUG=b:220084045
Change-Id: I449873fb85d590d9e7978a93648e90586ecfff10
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3473452
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Andrew Walbran <qwandor@google.com>
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>
When a client sends 0-sized data, the device regards that the client
closed the connection and will exit properly.
BUG=b:219674197
TEST=check if no error is shown when a vhost-user blk vmm disconnects
Change-Id: Icd84fb241c39b6dc54a8af41a068a6dd95ce4c2b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3468235
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
With VIRTIO_F_ACCESS_PLATFORM, virtqueues and desc chains of a
virtual device will receive IO virtual addresses. Mappings from
IOVA to GPA will be sent to virtio-iommu. `IpcMemoryMapper` is used
by the virtio device to get the translated addresses from the
virtio-iommu in another process.
Memory blocks with contiguous IOVA but discontinguous GPAs are
supported.
The only way to enable this new path is to hardcode the flag in
the features of each device. The flag should be automatically
for every virtio-vhost-user device in the future. It seems
questionable to add a per device command line option just for
testing.
BUG=b:215307964
TEST=cargo test/block device with VIRTIO_F_ACCESS_PLATFORM enabled
Change-Id: I9a89acf4f38d52816adad34c0dbff043677bebac
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3347309
Reviewed-by: David Stevens <stevensd@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Woody Chow <woodychow@google.com>
With crosvm adding support for windows, we want to make sure that
the line endings are not crlf.
git hooks and configs will be added as a part of another change.
Bug: b:213146393
Test: Modified Cargo.toml to have crlf endings and ran the script.
Change-Id: Ie6f53a7c0687578546e63770bb98706e4315a520
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3495708
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Vikram Auradkar <auradkar@google.com>
pvpanic is a simulated device through which a guest panic event could be
sent to the VMM. More details here:
https://github.com/qemu/qemu/blob/master/docs/specs/pvpanic.txt
Implement pvpanic device emulation and its pci interface.
BUG=None
TEST=Built crosvm. Ran a minimal vm to crash and verified that crosvm
receives the panic event. cargo test on devices.
Change-Id: I766fcc08f07760ad5f64f440a577705efd82e32a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3480575
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Vineeth Pillai <vineethrp@google.com>
On Manatee, all the pcie endpoint device are passed through into guest
and all the physical pcie root port are linked to virtual pcie root
port, if one pcie endpoint is connected to physical pcie rp statically
on host, this pcie endpoint should be connected to a virtual pcie rp in
guest statically. But current crosvm pcie could support hotplug device
only, it couldn't support connection device statically at boot time.
This commit add such support. if virtual pcie rp is used to
connect device statically, it won't use slot and won't have hotplug
capability.
BUG=b:185084350
TEST=On Byra-manatee, link all the physical pcie rp to virtual pcie
rp, then check NVME/SD/WIFI's function in CrOS, these devices are
connected to pcie RP on host directly.
Change-Id: Ie277c749da3c2020ad7361bf9ffa0271fb8f415d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3464512
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Since we'll be putting all PCI devices on non-root buses behind virtual
PCI-E root ports, MMIO BARs in such devices must be inside the forward
windows of their root ports. This presents additional requirements for
their MMIO BAR allocation:
1. All non-prefetchable BARs must be inside the same 32-bit MMIO window
2. All prefetchable BARs must be inside the same MMIO window, but
different than the non-prefetchable MMIO window
3. Both windows must be 1MB-aligned
4. No other PCI devices should occupy MMIO space in these windows
Allocate the entire window from the system resource allocator to prevent
any space within the window from being used elsewhere. To maximize
memory space efficiency, use VfioResourceAllocator for BAR allocation.
BUG=b:185084350
TEST=passthrough a vfio-pci device with bus_number > 0 and static connet it
behind a pcie root port, then check pcie RP and vfio-pci device function in
guest.
Change-Id: Ic9865afc48eb3ff9fa475dbcfdf90642b012980c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3166888
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Introduce the struct BarRange{addr, size, prefetchable} to indicate the
return of allocate_io|device_bars. So it is readable and easy to use.
BUG=b:185084350
TEST=boot Linux kernel and check dmesg
Change-Id: I0073f20401816f60c131bf15a9bc196e5fcba6d0
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3455126
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@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>
Split the logic in allocate_io_bars() into several parts in preparation
for the upcoming changes:
- collect_bars(): gather BAR information
- configure_barmem(): configure an MMIO BAR
- allocate_barmem(): main logic for MMIO BAR allocation
BUG=b:185084350
TEST=boot Linux kernel and check dmesg
Change-Id: I7eca48b16081dfd180ce4616239f568355e5031f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3166886
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Adding some conditional compilation flags so we do not need to
exclude them on each test run. None of there actually increase
the number of tests run, but gets us closer to being able
to run `cargo test --workspace`
BUG=b:218374759
TEST=./tools/presubmit --all
Change-Id: I181a84847fc09a4e1a6fb2b5f21538ebc400d607
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3453046
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
The merge can trigger conflicts if a change has been cherry picked
ahead of the merge. We always want to resolve conflicts by picking
the incoming version from cros/main.
BUG=None
TEST=./tools/chromeos/create_merge
Change-Id: I06694dd24b051fcdc12dbaccdbab552c72d7f2c4
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3494968
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
The MemoryMapping API has changed and these tests are not run by
default, which prevented us from catching this.
BUG=b:213149154
TEST=with crrev.com/c/3026355: cargo test --features "video-decoder,ffmpeg" -p devices virtio::video
Change-Id: I79a07d5a60c520d16190dd220b9a0f7501565e2c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3493533
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
The base version of MemoryMapping does not have the from_fd_offset
function. Use base::MemoryMappingBuilder and MemoryMappingBuilderUnix to
get the same functionality without depending directly on sys_util.
Fixes the build with virtio video features enabled.
BUG=b:213149154
TEST=emerge-hatch crosvm
Fixes: 45f1a419d4 ("Make crates depend on base instead of sys_util")
Change-Id: I8924d2334ae3d3ef489114b17071143871d1424d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3490743
Reviewed-by: Vikram Auradkar <auradkar@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
The sys_util implementation of From<MemoryMapping> for
MemoryMappingArena doesn't work with a base::MemoryMapping, since that
is a struct that wraps sys_util's MemoryMapping rather than a direct
re-export. Add an implementation that calls the sys_util impl with the
inner sys_util MemoryMapping.
BUG=b:213149154
TEST=emerge-hatch crosvm
Change-Id: I2a5cddade91f366b86b61cc4cf5b294c31fb1c4e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3490742
Reviewed-by: Vikram Auradkar <auradkar@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
When the client clears the output queue, it regains ownership of all the
currently queued output buffers. Unless the backend is made aware of
this, it will keep believing that it owns these buffers and may throw an
error when they are submitted again, so add a backend op to signal the
backend it should release all its output buffers.
The VDA backend does not make any such check, so its implementation can
be a no-op.
BUG=b:169295147
TEST=Android Youtube can play videos on Hatch.
Change-Id: Ia7d08e2499818e02a2bf56618852acdaee0d6d28
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3143585
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Backend errors are a single variant of VideoError and not matched by
themselves, so let's use anyhow instead of our own boxed error.
BUG=b:169295147
BUG=b:214478588
TEST=cargo build --features "video-decoder,video-encoder,libvda"
Change-Id: If5c056e8f8b6dfc0aec607d515db920bf1b83524
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3482935
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
As we make progress on upstreaming sys_util, we do not want more
dependencies on sys_util added. This check helps in that cause.
With this change only files that are inside common can depend directly
on sys_util.
Test: python3 ./tools/impl/check_code_hygiene.py common/sys_util_core
Bug: b:213149154
Change-Id: I57a8cb9189d3263a4031338b302cb27da799f4de
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3473344
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Auto-Submit: Vikram Auradkar <auradkar@google.com>
Commit-Queue: Vikram Auradkar <auradkar@google.com>
PciAddress is not really related to pci_root. Split it out so that it is
easier to find and so it can have its own tests nearby.
No code changes.
BUG=None
TEST=cargo build
Change-Id: I2bdad518de76587506593292cf0fbdb6b7066c1e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3475439
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Slot capabilities are only implemented if the root port is used for
hotplug. Allow PcieRootPort to be created with the option to not
implement slot capabilities and make all slot operations noops in that
case.
BUG=b:185084350
TEST=boot Linux kernel and check dmesg
Change-Id: I31410fc3e28d9d7cdc55edadcdb5e7dde796c5ce
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3166884
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
The TPM device was changed to manually include an edited subset of
common_device.policy in commit 25a86d99cc ("tpm: Update tpm device
policy to support libtpm2") because common_device.policy included rules
for open and openat at the time, and the TPM device needed to override
those rules. Now that common_device.policy no longer defines rules for
open and openat, it is safe to include the common policy instead of
duplicating it.
BUG=None
TEST=build with features=tpm and run with --software-tpm
Change-Id: Ia79d63fcf2cd2c5303384f4d0607b3b543406098
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3482029
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
sys_util_core won't have OS specific features so that sys_util and
win_sys_util can depend on it.
Makes Error::new() to accept generic type that implements TryInto<i32>>
Test: Presubmit
Bug: b:213149154
Upstream-Crate: common/win_sys_util
Change-Id: Ib99357634fdb00414a0ade7980a3d444770980ed
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3426382
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Vikram Auradkar <auradkar@google.com>
This was already allowed in common_device.policy for arm platforms, and
it can be called via future/async code that is used by many devices. Add
it to x86_64 and aarch64 common policies as well.
BUG=b:220908060
TEST=Start Crostini with virtio-snd on hatch and trogdo
Change-Id: I9bf8f56ebed0cfe6d5e17e45226cac73db3d6d37
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3482026
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
to support contiguous iova but discontiguous gpa memory block.
`MemRegion` also contains `perm`. `perm` allows R/W permission
enforcement.
The function will be used in virtio-iommu (CL coming soon).
BUG=b:215307964
TEST=cargo test
Change-Id: I37975480321a07741bfea232e9e6234cf0b93614
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3450022
Reviewed-by: David Stevens <stevensd@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Woody Chow <woodychow@google.com>
As CL:3423291 and CL:3428606 changed the path to store generated GitHub
pages contents in, we needed to chage it for cargo-doc as well.
BUG=none
TEST=check in my local GitHub repo
Change-Id: I27ae705c99968c060ede3ee514792d8ac1b7975e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3479038
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Fixed ACPI Description Table (FADT) contains Low Power S0 Idle Capable
Flag. This commit introduces "--s2idle" argument allowing to set proper
bit in the guest FADT table. This is required to inform guest OS to use
s2idle instead of traditional S3 power mode.
BUG=b:194391015
TEST=Build crosvm and run "crosvm run --s2idle ..", dump FADT table and
confirm that proper flag was set.
Change-Id: I243bfe2cc4840278fcdbf33dcb147b2eda50856d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3457402
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Grzegorz Jaszczyk <jaszczyk@google.com>
Use the existing register_memory() function that does the same thing as
the open-coded registration request.
BUG=None
TEST=tools/presubmit
Change-Id: I62956c2b4ceb288f7b76a4e85c27e288c496c73b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3470538
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
This reverts commit 73072d6d16.
Reason for revert: broke ARCVM GTS tests
Original change's description:
> virtio: video: encoder: set frame rate only if successfully changed
>
> Encoders Stream's frame rate was updated before a request was made.
> This could cause hypervisor to report incorrect frame rate to guest and other
> invalid behaviour if the request failed.
>
> This CL changes the order in which frame rate is updated. First a
> request is made, and then if successful, the frame rate is updated in
> the stream structure.
>
> BUG=b:160440787
> BUG=b:161774071
> TEST=v4l2-compliance -d /dev/video1
> TEST=v4l2-ctl -d 1 --set-fmt-video-out
> width=1280,height=1280,pixelformat=NV12 \
> --set-output-parm 10 --get-output-parm
> TEST=tast run eve arc.Video*
>
> Change-Id: I11a93d6d6338829ee0622f40f9b544a4ef2a69dc
> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3425362
> Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
> Tested-by: kokoro <noreply+kokoro@google.com>
> Commit-Queue: Marcin Wojtas <mwojtas@google.com>
BUG=b:160440787,b:161774071,b:220101996
TEST=GtsMediaTestCases com.google.android.media.gts.RtcVideoCodecTest#testDynamicFramerateChangeVp8
Change-Id: Ic10d93f0d3b29bef623ef3d9e3ff00d524a66ebd
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3474731
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Shao-Chuan Lee <shaochuan@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Device can be started with
crosvm device console --vfio <PCI ID>
BUG=b:213531730
TEST=console is usable from a sibling guest when using VVU.
Change-Id: Id19ea8d8d1e11f29a024a30b09622513ad8b172f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3429063
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Removed `vmm_vhost::Error::should_reconnect()` which we're not using at
all. We don't support reconnect feature at this point.
This function exists even in rust-vmm/vhost, but neither
cloud-hypervisor or rust-vmm/vhost-user-backend is using it.
BUG=none
TEST=cargo check
Change-Id: I4fda22d927573acfedcb189ad786aeb2cf7496e1
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3468234
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Vikram Auradkar <auradkar@google.com>
Reviewed-by: Noah Gold <nkgold@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
