Recent builds (starting R100.14501.0.0) crash when attaching a USB
device to the Linux VM due to calling the statx syscall, which was
missing from the seccomp policy. stat was already allowed, so add statx
as well to prevent the crash.
The change is likely due to the upgrade of the Rust toolchain in the
Chrome OS SDK (https://crrev.com/c/3439725), which landed in this build.
This was already allowed on arm/aarch64, so no other changes are
required.
BUG=b:218565401
TEST=Attach USB device to crosvm on hatch
Change-Id: Ia3a383429a839c68b44040f4b99c990a1f1f8e9d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3448188
Reviewed-by: Long Cheng <lgcheng@google.com>
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
The crate requires special compilation flags that conflict with the
workspace flags.
We may want to consider moving it to common/ so the test runner can
compile it in a separate workspace.
This brings us one step closer to be able to run
`cargo build --workspace` with no excludes.
BUG=b:206689789
TEST=./tools/presubmit
Change-Id: Ice747ced00f81db0a8e05ff2bc43d4d0e323e456
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3453050
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Add a "chromeos" profile that mimics the flags used when compiling for
Chrome OS. This is useful to determine how much the crosvm binary will
inflate due to a given CL.
Also add an "lto" profile enabling LTO on top of the "chromeos" profile,
so we can easily see how much space we save by enabling LTO.
BUG=b:218473401
BUG=b:218566754
TEST=cargo build --profile chromeos
TEST=cargo build --profile lto
Change-Id: I2fd743b6c980b847af1f3db593a55b683cbb8d57
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3450026
Reviewed-by: Anton Romanov <romanton@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
The new default should be quick, aarch64 tests barely take longer
than clippy/fmt and gives good enough coverage for most things.
The --all mode will add all other builds run by kokoro, including
armhf and a --no-default-features build.
BUG=b:203152778
TEST=./tools/presubmit (--quick, --all)
Change-Id: Ie778f397e9d65d9ca79bcb55acf0e74394bb04af
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3447293
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
While we can run armhf binaries on aarch64 or use user-space emulation
to run aarch64 tests on the x86 host, some tests will fail in that
scenario as they will interact with kernel APIs directly (e.g. kvm).
This will make it easier to distinguish 'do not run on armhf because
we haven't fixed the tests' from 'this test is not supported on
a foreign arch kernel and that is expected'.
It also enables a quicker method of running aarch64 tests with
user-space emulation.
BUG=b:218374759
TEST=./tools/dev_container ./tools/run_tests --target=host
--arch=aarch64
Change-Id: I81871e11d3b02ee1ed3bac88bada28fbba8a3f31
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3447292
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
On Windows os_handle is of type void*, can't use Into::into to cast to
i64. Use as i64 instead.
Test: launch_cvd
Change-Id: I7fe44dbadf5214ff9bfd81482f5b598091a8f692
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3448217
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Auto-Submit: Kaiyi Li <kaiyili@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Kaiyi Li <kaiyili@google.com>
They can't trust the host to provide entropy, so there's no point
providing it.
BUG=b:217506382
TEST=tools/dev_container tools/run_tests
TEST=tools/dev_container tools/run_tests --target=vm:aarch64
Change-Id: I5355e846191d34e10c0c5c3cf0b2afaa3c779313
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3450875
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Andrew Walbran <qwandor@google.com>
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>
crrev.com/c/3205229 introduced an associated type
`VhostUserBackend::Doorbell` to allow support different types for
vhost-user and vvu.
However, we finally concluded having it as an enum would be better
because it allows us to decide which vhost-user or vvu is used at
run-time so that we can share more code between vhost-user and vvu.
So this CL replaces the associated type with an enum value.
BUG=b:194137301
TEST=build
Change-Id: I60d7080e5d3bcd397ab70c8f9b83c7d6cd08bb92
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3353057
Reviewed-by: Chirantan Ekbote
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Enable VVU feature unconditionally.
Since kokoro will start checking VVU code from this CL, clippy errors
are fixed.
In addition, the time limit of kokoro unit testing needed to be
increased because some time-consuming unit tests will start running on
aarch64 QEMU, which is really slow.
BUG=none
TEST=kokoro
Change-Id: I67437c060ff5ba9f690dcfc6e5c3dd155b95a785
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3450014
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
and BasicMemoryMapper impl. This will be used for
VIRTIO_F_IOMMU_PLATFORM support in virtio-iommu.
BUG=b:215307964
TEST=cargo test/block device with VIRTIO_F_ACCESS_PLATFORM
with crrev.com/c/3347309 (to be submitted)
Change-Id: Iadd964556edf5b95aa00b542b4bde5a997756090
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3334331
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: David Stevens <stevensd@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Woody Chow <woodychow@google.com>
Add a safe helper function to call `VBFIO_DEVICE_GET_INFO` ioctl, which
will be used from VVU later
BUG=b:194136484
TEST=build
Change-Id: Ia3b797fba7cd77fc7698230e88a94e619485eaca
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3446522
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
This will allow reusing `MsixCap` for virtio-vhost-user in the later
CLs.
BUG=b:194136484
TEST=cargo test
Change-Id: I38bced958d42ce7e3192a54564628c9b559c4269
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3446521
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
This will still run the same tests as before, the options are just
more consistent now.
BUG=b:218374759
TEST=./tools/presubmit
Change-Id: I41a8730f6cfaf65a62aaa26c45e2c284f0356d33
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3447541
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Windows HANDLE is defined as void* which is incompatible with current
os_handle type i32. Change that to i64.
TEST=launch_cvd --gpu_mode=gfxstream
BUG=b:217977329
Change-Id: I78c6c4c0d7573773ed530d8987b932438222144f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3445529
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Kaiyi Li <kaiyili@google.com>
The patch disallows any platform specific code in sys_util_core and
doesn't let sys_util compile on windows platform.
This ensure to some extent that we keep sys_util and it's dependency
sys_util_core independent of windows code.
check_code_hygiene is not foolproof.
Test: Ran the script against a modified file in sys_util_core containing
string "target_os = "
Tried to compile sys_util on windows.
Bug: b:215610772
Upstream-Crate: common/win_sys_util
Cq-Depend: chromium:3433709
Change-Id: Ideb45092a959dd347d966633c3bd4e82f842b1a8
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3438709
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
sys_util_core won't have OS specific features so that sys_util and
win_sys_util can depend on it.
Test: Presubmit
Bug: b:213149154
Upstream-Crate: common/win_sys_util
Cq-Depend: chromium:3433709
Change-Id: I863f7a6bc7549944b4d114cca6d7be04c3093fc3
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3426380
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
proc-macro tests run on the host, adding logic into the test runner
to accomodate for that.
BUG=b:218374759
TEST=./tools/presubmit
Change-Id: I83c853b9e28dae725d299509f7e3a07f56bd6ad8
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3445531
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Adds use_uring checks to a few more test cases that are using the
URingExecutor.
BUG=b:218374759
TEST=./tools/run_tests
Change-Id: Ie5822dea4f22c2e8cffab13549c07873e89129d8
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3443634
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
It is not compatible with protected VMs and leads to crashes due to host
trying to access the guest ring buffers.
BUG=b:215516857
Signed-off-by: Sebastian Ene <sebastianene@google.com>
Change-Id: I110c8844903de20d9d3833d5dfdc25c3d41d2afb
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3439895
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Andrew Walbran <qwandor@google.com>
This is the last one. Just a few nits and we can now run clippy on all
crates.
BUG=b:192373803
TEST=./tools/presubmit
Change-Id: I93ad9ce3b1cf0718bda8588279d7e1a891a0a6f3
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3439052
Reviewed-by: Noah Gold <nkgold@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
The bindings need to be regenerated. Just disable warnings for now.
BUG=b:192373803
TEST=./tools/presubmit
Change-Id: Ia34638cbc20c4705631ea3693d4476137ebf8d55
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3439051
Reviewed-by: Noah Gold <nkgold@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Mostly issuses in bindings, which have just been suppressed.
The bindings will need to be regenerated in a separate CL.
BUG=b:192373803
TEST=./tools/presubmit
Change-Id: I653e4903778087943456fb82fc2643fed0f86314
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3439050
Reviewed-by: Noah Gold <nkgold@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
This adds a blanket allow to the top of the bindings file. The bindings
will need to be regenerated in a separate CL.
BUG=b:192373803
TEST=./tools/presubmit
Change-Id: I6554d17fffde2089e29bf2e7c184b8cac937db6d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3439049
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Just a few nit fixes and we can now enable clippy for this crate.
BUG=b:192373803
TEST=./tools/clippy
Change-Id: Ia6ab90fa33e979066d9eeae2372630d93cf4026a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3441343
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
When virtual pcie root port RTD3 is enabled, it will enter into suspend if child device
isn't exist. Pcie hp driver disable hotplug interrupt once it enters into suspend state,
so hotplug interrupt couldn't be injected into guest if pcie RP is in suspend state. In
such case a PME will be injected into CrOS to wakeup itself first, another hotplug event
will be injected after this PME.
BUG=b:185084350
TEST=Hotplug a vfio-pci device into CrOS with virtual RP RTD3 enabled
Change-Id: I96f8ac6ba27072f6cfbc01df00c0a48f2d92a7e5
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3423463
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
In order to link virtual pcie root port's power status with physical
pcie root port, power control capability should be added to let guest
enable RTD3 for virtual pcie root port.
BUG=b:185084350
TEST=check virtual pcie root port's RTD3 status in CrOS
Change-Id: I25e36b845b7ec198f995e82dda7850e4a1af0d9e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3423462
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
When pcie-root-port parameter is used to link virtual pcie RP with
physical RP, they should have the same bridge window size.
BUG=b:185084350
TEST=Boot CrOS with pcie-root-port parameter in ManaTEE and check
bridge window size in CrOS
Change-Id: I7864b37ecd61af52b470701803e746080f3a9025
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3423461
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Add pcie-root-port parameter, it specify host pcie root port's sysfs, then
it will have a virtual pcie root port in guest, as guest and host have
the same pci address, so virtual pcie root port creation should be prior
to build_vm().
BUG=b:185084350
TEST=boot CrOS with --pcie-root-port=sysfs_path in ManaTEE and check virtual
RP's function in CrOS
Change-Id: Id357e0de057d5387f135213e89702f27163faaee
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3423460
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
On ManaTEE, each physical pcie root port has a virtual pcie root port in
CrOS, this commit links virtual RP to physical RP. The following virtual
RP's config registers are from physical:
--devie ID
--device type
--bridge bus range
BUG=b:185084350
TEST=Check virtual pcie RP config registers in ManaTEE CrOS
Change-Id: Ia38a0f2417331d562dbb305433c68a3bee678bde
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3423459
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Currently bridge's PciAddress is allocated from system bus allocator,
but when virtual pcie root port is linked to physical pcie root port,
its PciAddress should be same as physical pcie RP, so thid commit let
bridge get its PciAddress from the backend pcie RP device, this is
convenient for later pcie root port.
This commit doesn't change function.
BUG=b:185084350
TEST=tools/presubmit
Change-Id: I2b81f6447898bd76758569095aa48f3daa2b0dcc
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3423458
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Currently pci bridge's bus range is managed in pci bridge structure, but
when virtual pcie root port is linked to physical pcie root port, the bus
range of virtual pcie RP should be same as physical pcie RP, so this commit
let bridge get its bus range from the backend pcie root port device, this
is convenient for later physcial pcie root port.
This commit doesn't change function.
BUG=b:185084350
TEST=tools/presubmit
Change-Id: I80c54365d6def455e32e7934e7216c677902450d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3423457
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
As more function are adding into pcie.rs, one file wil be larger. This commit
split pcie.rs into three files:
pci_bridge.rs: handle pci bridge device and implement PciDevice trait
pcie_device:rs: define PcieDevice trait and PcieCap
pcie_rp.rs: virtual pcie root port emulation, implement PcieDevice trait and
HotPlugBus trait
This commit doesn't change function.
BUG=b:185084350
TEST=tools/presubmit
Change-Id: I4ab16f35e78a9d084a7a47d91a7fcf37e9f3e91d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3423456
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
An async IPC translation request handler will be added for
b/215307964. This CL is preliminary.
BUG=b:215307964
TEST=cargo test/block device with VIRTIO_F_ACCESS_PLATFORM
with crrev.com/c/3347309 (to be submitted)
Change-Id: I1ce7b1c53e8efb3ae8652caba02693fee77646b1
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3382499
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>
The `run_until` method of the executor returns a Result<Result<..>>,
where the outer result signals errors within the async executor, and the
inner result is the actual result of the passed future.
The current error handling completely ignores this inner error, making
"crosvm device" exit silently if we e.g. specify a socket that already
exists.
Fix this by explicitly returning outer errors if they exist, and
returning the inner anyhow::Result as-is so both levels of errors are
properly reported.
BUG=None
TEST=cargo build
TEST=console device properly reports and error if its socket file
already exists.
Change-Id: I7d091bd7b0d66a07c6f340ebf9e395d0dab2c212
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3439668
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Anton Romanov <romanton@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
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>
Prior to this change, frame rate wasn't modified in video encoder input
and output params. This resulted in hypervisor reporting to guest a frame
rate equal to zero at all time. This is inconsistent with actual frame rate.
Futhermore frame rate equal to zero causes v4l2-compliance to fail.
This CL ensures that frame rate is stored in input and output stream
params and that its value is reported correctly to the guest. With this
change we remove field_rate from Stream struct to avoid storing the same
value in 3 saperate places instead 2.
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: Iff76a923d5f337db86fe67bfc77b13cd6bf58edf
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3417310
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Marcin Wojtas <mwojtas@google.com>
Till this point, frame size was stored in either input params or output
params depending on the device. This caused to virtio-video to report
zerod width and height on one buffer end, which caused v4l2-compliance
to fail.
This CL makes encoder and decoder store frame sizes in both params.
BUG=b:160440787
BUG=b:161774071
TEST=v4l2-compliance -d /dev/video0
TEST=v4l2-compliance -d /dev/video1
TEST=tast run eve arc.Video*
Change-Id: I77d8ab4c0ed1d0a877ed090b169a922606dcee70
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3412775
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Marcin Wojtas <mwojtas@google.com>
Previously most decoder initial parameters were set to zero due to use
of Default::default(). This caused decoder to start with incorrect values,
and led to v4l2-compliance failing.
This CL sets initial decoder parameters to artificially chosen values in
order to comply with v4l2-compliance.
BUG=b:160440787
TEST=v4l2-compliance -d /dev/video0
TEST=tast run eve arc.Video*
Change-Id: I283473d856e94087f039bc8f60c978c384f7f22c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3402215
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Marcin Wojtas <mwojtas@google.com>
Before this CL, both encoder and decoder had separate code which
computed plane formats for given format.
This CL removes code duplication, by introducing PlaneFormat::get_plane_layout,
which returns vector of plane formats if given format is supported. At
this point only NV12 is supported.
BUG=b:160440787
BUG=b:161774071
TEST=v4l2-compliance -d /dev/video0
TEST=v4l2-compliance -d /dev/video1
TEST=tast run eve arc.Video*
Change-Id: I427346d7e286a2e52aa4cbdc6e042a996812f3b1
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3425360
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Marcin Wojtas <mwojtas@google.com>
To help find missing feature cfg checks, add a build with all features
disabled to the CI scripts.
BUG=None
TEST=tools/presubmit
Change-Id: I98f38ecc3bf90cbeb081a1fafe4f2f540e4fc348
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3437362
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Add proper conditional compilation flags. This will largely still skip
most of those crates, but at least the syntax will be checked.
BUG=b:192373803
TEST=./tools/clippy
Change-Id: I66d29ccdfec01f3a83b682a9cc135188fdc830cb
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3438705
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Moving the GPU initialization earlier makes it so that the addition of
block devices does alter PCI slot of the GPU. This makes it so that
SELinux rules won't need to be changed any time we add a new device.
Without this patch, adding another disk breaks ARCVM for this reason.
BUG=b:199685490
TEST=local_test_runner arc.Boot.vm
Change-Id: I55e2a4c95cd5783108b0458e6cb2fc5f554e1847
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3433227
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Richard Fung <richardfung@google.com>
We used to bail early if an error happened while we run the console
device, leaving the terminal in raw mode.
BUG=None
TEST=cargo build
Change-Id: I3dc4a681f736246548d1cc7b7eab0bfd429587be
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3439667
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
