Restoring a snapshot on WHPX was failing with a SMP Linux guest. khei@
noticed that WHPX has a special "internal" register called
WHvRegisterInternalActivityState. This register is not in the Hypervisor
Top Level Specification, but it does appear in the WHPX headers & MSDN
docs. Its exact function is not specified, but by experimentation we
believe it contains state critical for SMP guests to restore
successfully (they restore successfully once this register is
saved/restored). Perhaps there is some IPI or kernel side LAPIC state
that is only available via this register, and that state is only
critical for SMP guests. In any event (pun intended), we treat the
register as opaque data, and that seems to work fine.
This CL also adds another register that we previously skipped over,
WHvX64RegisterDeliverabilityNotifications. This register is how we
request an interrupt injection window from WHPX for things like PIC
interrupts. Previously we weren't saving/restoring it, and it's possible
for such a request to be pending at snapshot time, so we shouldn't be
discarding that state as it could break things.
BUG=b:297294476
TEST=snapshotted & restored an Ubuntu SMP guest successfully.
Change-Id: I65c14432c9a56388bda7edeacfa21fe1fa8951a6
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4827931
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Noah Gold <nkgold@google.com>
Reviewed-by: Elie Kheirallah <khei@google.com>
It turns out the TSC adjust register in the VMCS is already handled for
us by the generic x86_64 code. Actually trying to restore the TSC MSR
will clobber that in a way do not want. (Our goal in snapshotting for
WHPX is to ensure that TSC adjust remains the same, not that the guest's
views a TSC that does not change across snapshot/restore. We rely on
virtio-pvclock to fix up the guest clock after the restore operation,
and it requires TSC adjust to remain constant.)
BUG=b:297294476
TEST=ran the emulator and snapshotted with pvclock enabled. The kernel
did not complain about clock issues.
Change-Id: I04306339d6c11a094d2c81a13f225927b9a89911
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4827930
Reviewed-by: Elie Kheirallah <khei@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Noah Gold <nkgold@google.com>
Relands 42ee99f25e ("gpu: allow unsandboxed implicit render server spawn") with changes.
Add command line argument allowing virglrenderer to implicitly spawn a
render_server process when a render_server_socket is not provided and
sandboxing is disabled. Useful for simplifying local debugging and injection-based
profiling (ASAN lib injection) workflows.
BUG=b:298221126
TEST=cargo build --features=gpu,x,wl-dmabuf,virgl_renderer,virgl_renderer_next
TEST=Run crosvm with virglrenderer without render_server support built-in - works by default.
Change-Id: I83b888f84dffe055d144d8c9aee67f8feff9c0e2
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4834111
Reviewed-by: Jason Macnak <natsu@google.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Ryan Neph <ryanneph@google.com>
Signal PCM worker on stream release to let the worker break out of the
main loop and be released successfully while CRAS is suspended/broken
and doesn't send data to the worker.
After receiving the stream release command, wait up to 2 periods to
respond to the last buffer and stop the worker. If 2 periods passed
without receiving a new buffer, then stop the worker anyway.
Originally this CL is to handle the case when CRAS is suspended, but we
fixed it by changing the suspend order. We found that this CL can help
with b/297454482 when the worker get stuck due to broken mic.
BUG=b:248470751, b:297454482
TEST=Open/Close stream in ARCVM multiple times and check there is no
"Error reading msg" or "fetch err" error
TEST=`atest android.media.audio.cts.AudioNativeTest#testRecordAudit
android.media.audio.cts.AudioNativeTest#testRecordStreamData` on
chronicler
Change-Id: If9185e46173971d06af934d5054a0dda2866c592
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4054215
Auto-Submit: Pattara Teerapong <pteerapong@chromium.org>
Reviewed-by: Chih-Yang Hsia <paulhsia@chromium.org>
Reviewed-by: Judy Hsiao <judyhsiao@google.com>
Commit-Queue: Chih-Yang Hsia <paulhsia@chromium.org>
This reverts commit 42ee99f25e.
Reason for revert: b/298221126 - accidentally enables render server for virglrenderer in undesired cases
BUG=b:298221126
Original change's description:
> gpu: allow unsandboxed implicit render server spawn
>
> Allow virglrenderer to implicitly spawn a render_server process when a
> render_server_socket is not provided and sandboxing is disabled.
>
> BUG=None
> TEST=cargo build --features=gpu,x,wl-dmabuf,virgl_renderer,virgl_renderer_next
>
> Change-Id: Icb682ffbf5812675d3c0c8e5a3d11006ecd53e8d
> Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4563457
> Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
> Commit-Queue: Ryan Neph <ryanneph@google.com>
> Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
BUG=None
Change-Id: I657b3537330618b3cae8ebff38ab39e525f38dd1
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4827920
Reviewed-by: Ryan Neph <ryanneph@google.com>
Commit-Queue: Jason Macnak <natsu@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
`update_virtual_display_projection()` calls into gfxstream, which may
take a long time to finish if we have a hard time acquiring a certain
lock in gfxstream (b/244201551). We will log the elapsed time and create
a B2T2 rule to catch hanging events.
Bug: 244201551
Test: Ran GPG and checked the log
Change-Id: I4055abc77bcbeeea465e6a79353d0e57fbb63acc
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4802517
Reviewed-by: Vikram Auradkar <auradkar@google.com>
virtio-input devices can receive events from the guest. Primarily this
is used controlling the numlock, capslock, and scroll lock lights. For
KiwiMouse, we'll be using LED 0 (the numlock LED) to allow the guest to
signal whether the mouse should be captured.
We need the capture information to be communicated from the virtio-input
device to SurfaceInput, but some of the plumbing is missing. Currently
we only support host -> guest data, and not the other way around (at
least in gpu_display_win). This CL adds a route for data to flow from
virtio-input to the gpu_display_win Surface via the
the GPU device worker & GpuDisplay::handle_event_device.
Bug: 239991275
Test: ran emulator & verified events were arriving in
on_handle_event_device as expected.
Change-Id: I7ab8e5ec51f7aa655b2cb44fe38483103388b53d
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4719210
Reviewed-by: Vikram Auradkar <auradkar@google.com>
The Req trait and related code relied on transmuting arbitrary u32
values into an enum that might not be one of the valid enum branches;
this has always been undefined behavior in Rust, and now it is actually
causing failures at runtime (tests compiled with Rust 1.71.1 in release
mode crash, since the compiler intentionally emits an illegal
instruction for the transmute in a test).
Rework the code so instead of transmuting it first and checking for the
is_valid() function later, we require Req to implement TryFrom<u32> and
make VhostUserMsgHeader::get_code() return a Result so that callers must
check that the code is indeed valid.
Ideally, this code should be refactored so that the VhostUserMsgHeader
is checked once when it is received rather than each time get_code() is
called, but that would be a larger change, so it is left as a potential
future cleanup.
BUG=b:297923761
TEST=cargo test --release -p vmm_vhost # w/rust-toolchain = 1.71.1
TEST=tools/dev_container tools/presubmit
Change-Id: I8d24dd9d81ee107f9ab43ea7bf68145c380364db
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4824412
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
After go/playcl/83699, the WndProc thread is the only thread that
accesses this tube, so we could change its type from Arc<Mutex<Tube>> to
Rc<Tube>, so that we no longer need to worry about deadlocking.
This tube was a field of struct DisplayParameters. That struct is used
for CLI arg parsing, however, we don't get this tube from CLI so the
code looks awkward. Besides, DisplayParameters specifies params for each
individual window, but we will likely only have one tube and share it
among multiple windows when we support multi-windowing. So, we can
remove it from DisplayParameters, and WindowProcedureThread will
distribute the clones of the tube to surfaces.
Bug: 257486521
Test: Ran GPG
Change-Id: Ic7adeb4a41c89d79e40820ad4d50e8d85c4e385c
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4804685
Reviewed-by: Noah Gold <nkgold@google.com>
Commit-Queue: Kaiyi Li <kaiyili@google.com>
Report the error from fs::read() if it fails, in addition to the path.
Also add an error for when both string and path are missing, and remove
the validation for this case in config.rs. This simplifies the cmdline
parsing code because it can now use the default deserialization method
instead of a custom from_str_fn.
BUG=b:283990685
TEST=tools/dev_container tools/presubmit
TEST=crosvm run --fw-cfg with string= and path= options
Change-Id: I37104ae00c9acda55f10fdd382ea727d5b59b6cd
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4795353
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Sebastian Hereu <sebastianhereu@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Also add a config test with a valid --fw-cfg with path, and check the
values returned by the valid config parse tests.
BUG=b:283990685
TEST=cargo test parse_fw_cfg
Change-Id: I80ccefa9f449e6fa4bdd56d55cf519e15a213d32
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4795352
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
This CL change the message when failed to get THP size from warning
to info, due to it will always use the fallback value on the THP
disabled host environment.
BUG=b:296176956
TEST=CQ
Change-Id: I751d58d12b2ab571e0362221eb35f5d37adf916f
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4816246
Reviewed-by: Shin Kawamura <kawasin@google.com>
Commit-Queue: Shengsong Tan <sstan@chromium.org>
Reviewed-by: David Stevens <stevensd@chromium.org>
Partly fixes the mingw --no-default-features build. The network config
code is still broken because net structs are only available when the
slirp feature is enabled on Windows, but the uses of the config structs
are not protected with the same cfg check.
BUG=b:260607247
TEST=cargo build --target x86_64-pc-windows-gnu --no-default-features \
--features=slirp
Change-Id: Ia2f6e7baf769245135ef5ff48ee6fb2c4578f319
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4818989
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
We used to spawn a separate thread to poll gpu_main_display_tube for
messages from the external supervisor, and then wrap those messages in
thread messages (WM_USER_HANDLE_SERVICE_MESSAGE_INTERNAL) that are
posted to the WndProc thread. Now that we have replaced GetMessageW() with
MsgWaitForMultipleObjects(), we can poll that tube and the message queue
at the same time in the WndProc thread, and then route service messages
to WindowMessageDispatcher::process_service_message().
The newly added MsgWaitContext looks similar to EventContext but it is
much simpler, since we don't need to worry about removing handles,
setting timeout, etc. It may get more complex when we start to add more
handles to it (for event devices, etc.), and we might look for ways to
unify the logic with EventContext, but this simple struct should suffice
for now.
Bug: 244489783
Bug: 244491590
Test: flat run emulator
Test: flat run battlestar
Change-Id: I5722523ad1424a1860f2883d33728a1baf9550cc
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4719209
Reviewed-by: Pujun Lun <lunpujun@google.com>
Reviewed-by: Noah Gold <nkgold@google.com>
Commit-Queue: Kaiyi Li <kaiyili@google.com>
Currently we have two display event loops, one in the GPU worker thread
(mainly used by other platforms; we just poll event devices and the
display closed event there) and one in the WndProc thread (for handling
Windows specific window messages). We are exploring the possibilities of
merging those loops.
MsgWaitForMultipleObjects() allows us to wait for window messages and
other events at the same time. As the first step of our experiments,
we will use it to replace GetMessageW() while keeping everything else
unchanged. Simple performance tests show that there is no regression in
the average latency between we posting a message to the message queue
and we finishing retrieving it from the queue.
Bug: 244489783
Test: Ran GPG
Change-Id: I2ccea348459fa7af0a2ee0ac55e7c817f222a2f6
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4719208
Reviewed-by: Pujun Lun <lunpujun@google.com>
Commit-Queue: Kaiyi Li <kaiyili@google.com>
Reviewed-by: Noah Gold <nkgold@google.com>
This will be run by default by CI builders, but not locally as it
invalidates the build cache.
BUG=b:260607247
TEST=dev_container presubmit --no-delta all
Change-Id: I75f3d97bda6881a343364875e53e529a39ff168a
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4818791
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
In contrast to docker, podman will not pass-through SIGINT unless
--interactive is specified.
This change enables interactive mode by default if a tty is present,
and allows Luci builders to disable this behavior with the new
--no-interactive flag.
BUG=b:275613273
TEST=dev_container presubmit - then CTRL-C
Change-Id: Ic4900a0669b8c423316196abb289516aa618101d
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4818790
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
If PeekMessageW() does retrieve a message, we are responsibe for
dropping it.
Bug: 244489783
Test: Ran GPG
Change-Id: I69250387cc93698513a47d38de52d161a0026692
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4719207
Reviewed-by: Pujun Lun <lunpujun@google.com>
Reviewed-by: Vikram Auradkar <auradkar@google.com>
Commit-Queue: Kaiyi Li <kaiyili@google.com>
This flag is used by luci builders to force non-interactive mode.
The logic is temporary to allow us to change the defaults for the
interactive mode / tty logic in a follow-up CL.
BUG=b:275613273
TEST=dev_container --no-interactive run_tests
Change-Id: I93f315d5f65ed184e9c400531b115cc94312c95f
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4818789
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Similar to virtio-balloon, feature acks were not being tracked properly
and caused snapshotting to fail. This CL applies the same fix we used on
the balloon device.
BUG=b:297294476
TEST=snapshotting doesn't fail on this device anymore.
Change-Id: I6a4faa088eadf043fcc49479e3e565af18dbaa96
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4814771
Reviewed-by: Frederick Mayle <fmayle@google.com>
Commit-Queue: Noah Gold <nkgold@google.com>
