Two small tweaks:
- The original check had a typo ('features' vs. 'feature').
- Use the cfg! macro to simplify the code (cfg_if! is not needed here).
BUG=None
TEST=tools/presubmit --all
TEST=crosvm CQ
Change-Id: Icf84c24cb7f34bf4629e99ee1d7d33676e7ae8c1
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4126555
Auto-Submit: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
This CL adds a new backend for the cros_tracing crate. This backend can
be enabled by building crosvm with the trace_marker feature enabled.
When the feature is not enabled, no extra overhead incurs as the default
NOOP cros_tracing crate will be compiled in instead.
BUG=b:259501910
TEST=compiled and ran crosvm with and without `--features trace_marker`
Change-Id: Ia4b929b042712a458b7d54c0362d6fda90db9e9f
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4075413
Reviewed-by: Christian Blichmann <cblichmann@google.com>
Auto-Submit: Morg <morg@chromium.org>
Commit-Queue: Morg <morg@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
We were always passing a `0` for `ui_exceptions` for the sandbox
policy's job object, where we should have been passing the value
specified in the policy. This meant we were stricter than we specified
in the policy, but also that we could not be as strict with our job
object as we wanted to be, as we couldn't make use of exceptions.
BUG: b:262445398
TEST: Built and ran windows crosvm downstream.
Change-Id: I7df0282dbfadb33550956c2461b7dc084116617f
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4103909
Reviewed-by: Vikram Auradkar <auradkar@google.com>
Commit-Queue: Richard Otap <rotap@google.com>
Currently the only way to open a DRM device for libva is to scan the
list of DRM render nodes using udev. This works nicely for the general
case, but requires a few extra ioctls that are not currently added in
the video device process seccomp allowlist so we would like to get rid
of it.
One can also argue that how to detect the DRM device should be left to
the application, so this CL allows users to explicitly specify which DRM
device they want to open. As a helper, it also adds an iterator over
standard DRM render nodes locations to provide similar functionality
without requiring extra ioctls.
BUG=b:262824148
TEST=ARCVM can start and create a VAAPI-backed video device without
triggering seccomp policy failures.
Change-Id: I241c4834361ec1e8455a4307093850a7b3cef276
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4112728
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Frederick Mayle <fmayle@google.com>
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.corp-partner.google.com>
Add implementations to functions sleep, wake, snapshot, restore.
Sleep and wake only modify the device state to avoid reading/writing in
sleep.
Bug=b:232437513
Test=tools/dev_container tools/presubmit --all
Change-Id: I68e293a227471dc6b70fc5e78397c4745d48735e
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4096009
Auto-Submit: Elie Kheirallah <khei@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Elie Kheirallah <khei@google.com>
Reviewed-by: Steven Moreland <smoreland@google.com>
When the Vulkano feature is enabled, we create a vulkano-gralloc. But,
some users can be running the host-ANGLE stack, never using Vulkan.
Potentially, they have no Vulkan devices, which would fail
vulkano-gralloc.
The simplest change to avoid this is to make a vulkano-gralloc error
acceptable, by issuing a stern error! and continuing. Then, it is
safe to enable the Vulkano feature without worrying about breaking
existing users.
BUG=b:243061269
TEST=Manually error'd in vulkano-gralloc but still launched emulator
Change-Id: Ic39e1c6c43b208e41aed3ecc86b4876aaf47d729
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4119065
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Idan Raiter <idanr@google.com>
The increase_inode_refcount() function just needs a temporary reference
(&InodeData), not a full Arc<InodeData>. Removing the Arc::clone() gets
rid of a few extra atomic operations, since the Arc would be cloned and
then dropped immediately after calling increase_inode_refcount(), even
before leaving the calling function.
BUG=b:261922849
TEST=boot arcvm on brya
Change-Id: I285f0a31150695fb8ebeebc2c9d4c33a71702833
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4116248
Reviewed-by: Morg <morg@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
There seems to be no downside to holding self.inodes.lock() for the
whole PassthroughFs::add_entry() function. We don't do any siginificant
amount of work while the lock is held; either the inode already exists,
in which case we increment its refcount, or the inode is added to the
map. Note that we already opened the file before entering this function,
so the lock is not held across open().
This also prevents the possible race between threads opening the same
inode simultaneously, so remove the related comment.
BUG=b:261922849
TEST=boot arcvm on brya
Change-Id: I036ebaed179f7ac43d071a26cb68ba9a131521a0
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4116247
Reviewed-by: Morg <morg@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
The VAAPI decoder backend needs to open the DRI render node in order to
function. Add the necessary code to allow this to happen in a jailed
environment.
BUG=b:262824148
TEST=ARCVM can start and create a VAAPI-backed video device.
Change-Id: I130963ab9c2d1d0a008b674f0f606fa2dbba8dd9
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4112727
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
This allows `crosvm run` to work without requiring a `--gpu` option,
which matches the behavior on Linux. The VM is fully functional and can
boot a Debian guest to a working login prompt and shell on the serial
port.
BUG=b:243061269
TEST=tools/dev_container tools/run_tests --platform=mingw64
TEST=boot x86-64 Linux bzImage on Windows
Change-Id: I828893cb6349c39b971aca0fccaa67c3238a7f3d
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4108050
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Idan Raiter <idanr@google.com>
Reviewed-by: Zihan Chen <zihanchen@google.com>
No functional change, just reorganizing the code that requires a
GpuVmmConfig into a separate function.
BUG=b:243061269
TEST=tools/dev_container tools/run_tests --platform=mingw64
Change-Id: I172579fa26ccdbc1c6cb1b8c1c6ac90d8bf37635
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4108049
Reviewed-by: Zihan Chen <zihanchen@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Idan Raiter <idanr@google.com>
This is a reland of commit 55a9bccead
The fix is to make sure we drop to the lock guard acquired by the
inodes mutex, so we don't end up in a deadlock. By splitting the if
statement and separating the else block, the guard is dropped
automatically.
Original change's description:
> fs: Reduce number of open() calls in passthroughfs
>
> Instead of always opening a new file every time we do an entry lookup,
> check first if the entry already exists in our inode map.
>
> I ran a trace test while loading a game on arcvm with and without this
> patch.
>
> Without patch:
> System-wide trace:
> newfstatat calls = 19211
> openat calls = 13189
> ~68% ratio of all newstat() calls vs openat() call
>
> virtiofs trace:
> newfstatat calls = 11958
> openat calls = 9899
> 82% ratio of virtiofs newstat() calls vs openat() call
>
> With patch:
> System-wide trace:
> newfstatat calls = 20242
> openat calls = 12954
> 64% ratio of all newstat() calls vs openat() call
>
> virtiofs trace:
> newfstatat calls = 2223
> openat = 273
> ~12% ratio of virtiofs newstat() calls vs openat() call
>
> This is a significant reduction of unnecessary syscalls in virtiofs
> (82% -> 12%)
>
> BUG=b:261922849
> TEST=loaded a game in arcvm and compared syscall % count
>
> Change-Id: I28acbae05900d9735ba3730ee106368ddc792476
> Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4091563
> Auto-Submit: Morg <morg@chromium.org>
> Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
> Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Bug: b:261922849
Change-Id: Ib885cb5f2b3f725405df2eecc641228042ea2093
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4105201
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Auto-Submit: Morg <morg@chromium.org>
This reverts commit ca90b4d1bd.
Reason for revert: This causes issues for Cattlefish
Original change's description:
> devices: virtio: create the Executor for the block before jail
>
> To utilize the io_uring-based Executor with the sandbox, each device
> must create any `Executor`s before jailing.
>
> This commit has the virtio-blk device make its `Executor` in `new`
> method, which is called in the main process before jailing. This change
> allows the virtio-block device to run in the sandbox with io_uring.
>
> BUG=b:251039942
> BUG=b:262341514
> TEST=`crosvm run --rwdisk path=blkdisk.img,async_executor=uring` runs
> with and without the sandbox
> TEST=`crosvm run --rwdisk path=blkdisk.img,async_executor=epoll` runs
> with and without the sandbox
>
> Change-Id: Iadb002d436a9d45f63220528273f9d2e283fbd88
> Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4098933
> Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Bug: b:251039942
Bug: b:262341514
Change-Id: I23097d929a0e9f680e3aaa02f4d83d8f7e1ddb26
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4114052
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Auto-Submit: Takaya Saeki <takayas@chromium.org>
There is no mechanism in the vhost-user protocol for the VMM side to
ask the backend device for its max queue size, so the only way to ensure
compatibility with arbitrary VMM frontends is for the backend to support
the maximum valid size. The maximum queue size for both packed and split
virtqueues is 32768 (2**15), so we can use that as the max queue size
for all device types. The VMM frontend can still choose a smaller queue
size when it sends the VHOST_USER_SET_VRING_NUM request.
BUG=b:262291811
TEST=tools/presubmit --all
TEST=Boot x86-64 Linux from a vhost-user block device attached to crosvm
Change-Id: Ie685ea7718f738ef19c1bc27132bbe5fc0466607
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4098493
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Previously flag `--vhost-net` had no effects if a tap device is
provided by `--tap-fd` or `--tap-name`. `--net` did not support
`vhost-net=true` for the two cases neither.
This commit adds vhost-net support to those two cases.
TEST=tools/presubmit
TEST=cargo test -p devices
BUG=None
Change-Id: I38d149d76512e5b56e5b86e129bf44afe12a1d9a
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4081878
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Changyuan Lyu <changyuanl@google.com>
The VhostUserParams struct uses a fake flattening technique to allow the
addition of the `vhost` parameter, but it relies on FromArgValue, not
Deserialize. Make sure to call the right method and add a TODO item so I
don't forget to revisit before enabling configuration files for the
`devices` command.
BUG=b:262345003
TEST=crosvm devices --serial vhost=/tmp/vu-console,type=stdout,hardware=virtio-console,console=true
Change-Id: I4948ca8185a475d41ab0e9c547628455de71188d
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4105302
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Auto-Submit: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Takaya Saeki <takayas@chromium.org>
This commit has vhost-user devices implemented by `VhostUserDevice`
trait call `Executor::new()` before jailing, not after jailing . The
context is the jail for io_uring. For the effective io_uring jail, an
`Executor` must be created before jailing.
Currently, the virtio-block and the virtio-console are implemented by
`VhostUserDevice` trait. Thus, this change enables vhost-user block
and console to work with io_uring in the sandbox.
This change also updates the doc comment of `VhostUserDevice`.
`Executor` can be actually kept during jailing as this change does, so
the current doc comment is obsoleted. However, `VhostUserDevice` is
still powerful to ensure that every initialization for
`VhostUserBackend` is done in the jailed process.
BUG=b:251039942
BUG=b:262341514
TEST=`crosvm devices --async_executor uring --block ...` works with the frontend.
TEST=`crosvm devices --async-executor uring --jail --block ...` works with the frontend.
TEST=`crosvm devices --async_executor uring --serial ...` works with the frontend.
TEST=`crosvm devices --async-executor uring --jail --serial ...` works with the frontend.
Change-Id: I1365ef96c2f2f27cd63bdeb3d0ca327100a5dcdc
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4098934
Commit-Queue: Takaya Saeki <takayas@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Minijail requires the `keep_rds` list to be unique, so you need to
deduplicate it before passing it to Minijail. This commit fixes missing
deduplication for the vhost-user devices.
This commit also fixes the wrong usage of `Vector::dedup()` of the
vhost-user fs device.
BUG=b:262339813
TEST=./tools/presubmit passes
Change-Id: Id8d8a5fb327a75a938315601ba67a91a698972c6
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4112720
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Takaya Saeki <takayas@chromium.org>
To utilize the io_uring-based Executor with the sandbox, each device
must create any `Executor`s before jailing.
This commit has the virtio-blk device make its `Executor` in `new`
method, which is called in the main process before jailing. This change
allows the virtio-block device to run in the sandbox with io_uring.
BUG=b:251039942
BUG=b:262341514
TEST=`crosvm run --rwdisk path=blkdisk.img,async_executor=uring` runs
with and without the sandbox
TEST=`crosvm run --rwdisk path=blkdisk.img,async_executor=epoll` runs
with and without the sandbox
Change-Id: Iadb002d436a9d45f63220528273f9d2e283fbd88
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4098933
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
add info when a device being restored doesn't have data in the snapshot.
No action would be taken on the device.
BUG=b:232437513
TEST=tools/presubmit --all
Change-Id: I67b5450f63aae693b44cb8cddda6d41aa88e6c9d
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4114640
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Elie Kheirallah <khei@google.com>
Auto-Submit: Elie Kheirallah <khei@google.com>
Reviewed-by: Frederick Mayle <fmayle@google.com>
No need for separate module.
BUG=b:173630595
TEST=compile
Change-Id: Ia88d64a9546322a9502fcd5bb24a0b6b9607a5d4
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4114022
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
If a child process exited, crosvm would exit with a status indicating a
success, as if the guest had requested a shutdown.
That behavior seems generally undesirable, but it has an added side
effect in Android, where some of the debug utilities (e.g. debuggerd)
work by forking the debug target (i.e. crosvm in this case), then, when
the debug fork exits, crosvm immediately exits itself. This CL doesn't
fix that, but at least makes it more obvious that something bad
happened.
BUG=b:238324526
Change-Id: I8fd86488f9401217100b82d433ea3d4f107ac526
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4108770
Reviewed-by: Steven Moreland <smoreland@google.com>
Commit-Queue: Frederick Mayle <fmayle@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
PCIe root ports can raise PME for any of its children, and hence should
not be limited to raise PME for the port itself.
BUG=b:241526471
TEST=builds and boots borealis
Change-Id: I784e579c97424f0baa7190cd73b69d7a1d6f88b8
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4105337
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Victor Ding <victording@chromium.org>
Auto-Submit: Victor Ding <victording@chromium.org>
Visibility should be as minimum as possible in general.
The fields of Net was `pub(super)` so that windows support can create
the Net instance from `new_slirp()`.
Introducing `Net::new_internal()` enables to make the fields private and
also move the duplicated logic (e.g. creating kill_evt) into
`new_internal()`.
BUG=b:237342367
TEST=cargo build
Change-Id: Ieff79bbdc5cd8efa88caa00155d9c80cb51cc47f
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4105332
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Shin Kawamura <kawasin@google.com>
The ///-style docstring at the top of RunCommand was included in the argh
help output (`crosvm --help` and `crosvm run --help`), but the bulk of
the comment is intended for developers, not for users of crosvm.
Move the run subcommand's help to an explicit #[argh(description = "")]
so the docstring is not used as the help text.
BUG=None
TEST=crosvm --help
Change-Id: Iccb702203f376c304fc2825eec42471a3b48efd9
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4109471
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
CrosVM supports PME and hence the PME bit in _OSC should be set.
BUG=b:241526471
TEST=Dump DSDT and verify
Change-Id: Ibc2cbec7096f7025724176834a9ae84c2ab18f04
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4105336
Auto-Submit: Victor Ding <victording@chromium.org>
Commit-Queue: Victor Ding <victording@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
The vhost-user VMM code does not depend on the corresponding backend
being enabled (or even implemented) on the current platform. Enable all
devices unconditionally to simplify the vmm/mod.rs code and ensure that
the vmm code does not grow any new dependencies on platform-specific
imports.
The resulting Windows binary should not be any different, since it will
not call any of the newly-added device creation functions, but this
allows the cleanup of some unnecessarily platform-specific code.
Additionally, remove the unnecessary wildcard exports of each device
module, since the devices are just extra functions added to the
VhostUserVirtioDevice impl.
BUG=b:262291811
TEST=tools/presubmit --all
Change-Id: I0b7d6ee1ab75e5ca5e97216aef0b39018192bbd6
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4098575
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Noah Gold <nkgold@google.com>
PCI and PCIe Specs describe the whole concept as PCI Power Management
Interface, and these registers as, for example, Power Management
Capabilities, Power Management Control/Status, etc. Therefore, PM (Power
Management) is a more accurate acronym than PMC (Power Management
Capabilities).
Linux also uses `pm` (`pci_pm`) instead of `pmc`.
No functional changes.
BUG=b:241526471
TEST=builds and boots borealis
Change-Id: Icab1a3fb3708b4e1fa65eeef918ecc8c047d177a
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4105335
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Auto-Submit: Victor Ding <victording@chromium.org>
Replace the hand-written bindings in the virtio-fs device with
automatically generated bindings from bindgen.
BUG=None
TEST=./virtio_sys/bindgen.sh
Change-Id: Ia11a2d97f3546515196a41764107e7aaece8ad82
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4103907
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Serial parameters fields should use kebab-case. Enforce it and add
aliases for fields using underscores for backward-compatibility.
BUG=b:255223604
TEST=cargo test -p devices
Change-Id: I2adf7f4161a83d32bca389fc413311b7f02216ce
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4105301
Auto-Submit: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Takaya Saeki <takayas@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
For both virtio-net and virtio-vhost-net devices, clean up creation
code by providing a single new() function accepting a tap device.
Move tap device creation code to device_helpers.rs.
Booted VM with `--net tap-name=crosvm_tap` and
`--net host-ip=192.168.1.1,netmask=255.255.255.0,mac=\
42:70:eb:61:1a:81,vhost-net=<false|false>`. Guests can ping
the host.
Tested that `cargo test -p devices` passes.
TEST=tools/presubmit
BUG=None
Change-Id: I75a3d47ba8750486abaa8ab70deea1805a7fc055
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4096607
Commit-Queue: Changyuan Lyu <changyuanl@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
The windows code is build only for now because
- crosvm upstream windows code needs some changes to be runnable
- LUCI windows infra is not ready for nested vm
BUG=b:253498690
TEST=ran `cargo t --features all-msvc64 -p e2e_tests` downstream
Change-Id: I318f6f17fc91bc76cfd28741a526193362ab4e50
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4096606
Commit-Queue: Vikram Auradkar <auradkar@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
This test ensures that the decoder backend is working as expected from
crosvm's perspective, so add it.
We only add the guestmem to guestmem test as virtio object import
required actual DMABUFs with VAAPI, which our current dummy object
building code does not allow to create.
BUG=b:214478588
TEST=cargo test --features "video-decoder,vaapi" -p devices vaapi -- --ignored
Change-Id: I1e2a03262ef30d4dacbd9ae4314e158b6bcae428
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4096401
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Now that the H.264 decoder test function is generic, move it to the
parent module so other backends can also use it.
BUG=b:214478588
TEST=cargo test --features "video-decoder,ffmpeg" -p devices ffmpeg
Change-Id: I2ecc9fe09dd85c6d85a77f9e8e19005f55447a73
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4096400
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
