Allow the RTC to re-assert the SCI when it is resampled, to
make sure that wakeup events which occur during suspend actually wake up
the guest. Similar to GPEs, cmos passes an Event that will be
signaled when the RTC is cleared.
BUG=b:301862490
TEST=Manual test with ArcS2Idle feature flag
TEST=manual tests with rtcwake
Change-Id: Ife667e46e6a89ea9dcb868696493f401758988a7
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5512664
Commit-Queue: David Stevens <stevensd@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Allow virtio devices to re-assert the SCI when it is resampled, to make
sure that wakeup events which occur during suspend actually wake the
guest up. This is done by passing an Event as part of the VmRequest::Gpe
message, and re-asserting the SCI until the virtio device signals the
Event.
BUG=b:301862490
TEST=Manual test with ArcS2Idle feature flag
Change-Id: Ib2067e2cb6c41e886f3414e9a8c4e7c61048dfb9
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5491344
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: David Stevens <stevensd@chromium.org>
This avoids the need to clone the path when calling do_restore(). The
do_restore() function itself can convert the Path reference into an
owned PathBuf as needed, cleaning up the callers.
BUG=None
TEST=tools/dev_container tools/presubmit
Change-Id: Ie43813ee4299d44319bb907a645abc544c99dad4
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5506737
Reviewed-by: Frederick Mayle <fmayle@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Allow the RTC to un-suspend VCPUs, to wake the guest up from S3.
BUG=b:301862490
TEST=Manual test with ArcS2Idle feature flag
Change-Id: Ida9934d8c7caafc507dbadcc0c45ad5edbfd4b2d
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5491347
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: David Stevens <stevensd@chromium.org>
Introduces a new switch/option on snapshot commands/IPCs that turns on
encryption using the crypto crate.
BUG=b:286345300
TEST=builds upstream; tested end to end downstream.
Change-Id: Ia04074bb23332274d4e6b99eb242c84b0af7a8a9
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5371444
Reviewed-by: Frederick Mayle <fmayle@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Noah Gold <nkgold@google.com>
This CL introduces the USB backend device provider logic to handle
attaching security keys to the backend.
BUG=b:297957754
TEST=presubmit
Change-Id: I5849ad617b41a9d8ddb0127d9167ee02b27cd8da
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4945571
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Several crates still declared a dependency on data_model despite not
using any imports from it.
BUG=b:312312646
TEST=tools/dev_container tools/presubmit
Change-Id: I63a67696c205f684b1e4ac8bdad4de5f294b63dc
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5370964
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Spawn a stub_worker thread as a part of the device initialization to
avoid blocking PvClockCommand request when the device is not activated
yet. After this change, the requester of PvClockCommand can expect the
response from the device even if the device is not active. This can
happen when the guest kernel does not support the PvClock device and
because of that the device is not activated (from the virtio device
perspective).
BUG=b:295256641
TEST=cargo test -p devices -- pvclock
TEST=cargo test -p e2e_tests -- suspend
Change-Id: I0efc10bbf0e1125bf2df9208e1d6bcc341867a7e
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5312037
Auto-Submit: Hikaru Nishida <hikalium@chromium.org>
Commit-Queue: Hikaru Nishida <hikalium@chromium.org>
Reviewed-by: David Stevens <stevensd@chromium.org>
RAM snapshot size and overall snapshot time for a basic ubuntu VM right
after login:
* no compression: 619M 0.8s
* lz4 compression: 175M 1.2s
BUG=b:320753724
TEST=crosvm snapshot take --compress-memory /tmp/crosvm-snapshot /tmp/crosvm-control
Change-Id: I5dff9fe8744847fea872ad78347ac5f7d8b957e3
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5190788
Reviewed-by: Elie Kheirallah <khei@google.com>
Commit-Queue: Frederick Mayle <fmayle@google.com>
Reviewed-by: Noah Gold <nkgold@google.com>
Example command:
crosvm gpu set-mouse-mode <control_socket_path> \
--display-id=0 \
--mouse-mode=relative
This enables the Windows implementation to toggle mouse capture
mode (touchscreen <-> relative). It will have no effect if the
specified "display-id" doesn't point to an existing guest display
associated with an in-use host display.
BUG=b:324087519
TEST=presubmit
Change-Id: I9e513eb692d4b9cba66eb1e629ab8f7018645059
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5319794
Reviewed-by: Noah Gold <nkgold@google.com>
Commit-Queue: Pujun Lun <lunpujun@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Using serde_json on unbuffered readers/writers is slow.
Change-Id: Ie22f09e317d86d44263805e6f850ee96c0f0aa04
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5325901
Reviewed-by: Noah Gold <nkgold@google.com>
Commit-Queue: Frederick Mayle <fmayle@google.com>
Turns out impl Trait in return position means we only get *one* concrete
return type for all branches. In a future CL we'll have multiple return
types, so paradoxically, we'll have to think inside the Box.
BUG=b:326170473
TEST=builds
Change-Id: If759995d47e717adfeae6153f81f9940062e1e4e
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5320337
Reviewed-by: Frederick Mayle <fmayle@google.com>
Commit-Queue: Noah Gold <nkgold@google.com>
The current SnapshotReader/Writer interface returns Files for raw
fragments. When we add snapshot encryption, we will need to return an
encrypting or decrypting streaming wrapper, and this won't be a File.
This CL changes the interface to return impl Read or impl Write. As
part of that, we also had to make a significant safety change to
how memory snapshots are taken.
Memory snapshots used to be written with FileReadWriteVolatile. This is
because we assume GuestMemory is always mutably borrowed by the guest,
and it is UB to have aliased references in Rust. While formally
undefined, the rough reasoning for this is that LLVM optimizations
assume noalias on mutable references, and if that is violated at
runtime, optimizations can result in changed behavior. In the snapshot &
restore case though, we know the guest is not running because its VCPUs
are stopped, so its mutable reference can be ignored (temporal overlap
for aliasing is required for UB to occur). Luckily for us, the host code
will never alias guest memory because up until this CL, we assumed that
was never safe.
Credit: thanks to fmayle@, who originally proposed using Read/Write in this
manner in a CL that added snapshot compression.
BUG=b:326170473
TEST=builds
Change-Id: Iafd9175f684bc197329a0f5aae57685f5cfd677e
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5313630
Reviewed-by: Frederick Mayle <fmayle@google.com>
Commit-Queue: Noah Gold <nkgold@google.com>
Certain platforms use the noncoherent-dma feature to appropriately
consider the guest PAT's memory type (caching mode) when configuring the
effective memory type in SLAT, instead of simply ignoring it in favor of
the host PAT.
Dynamic blob mapping has already integrated support for noncoherent-dma
upon setting up each mapped blob's memory region (e.g. KVM memslot),
but fixed_blob_mapping merged while naively ignoring the feature.
Now, we respect the feature when setting up the shared/prepared memory
region (appropriately passing the new MemCacheType enum through to the
hypervisor).
BUG=b:246334944
TEST=tools/presubmit
TEST=(in venus-enabled VM w/ noncoherent-dma) `deqp-vk -n dEQP-VK.memory*` passing
TEST=(in venus-enabled VM w/ noncoherent-dma) Hollow Knight, Portal 2,
Valheim, CS:Source all look fine.
Change-Id: Ia31763c80765a42a1932bfb347ffa57a2faf6fab
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5285309
Commit-Queue: Ryan Neph <ryanneph@google.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Before this change, each guest synchronous virtio-gpu
VIRTIO_GPU_CMD_RESOURCE_MAP_BLOB submission would provoke crosvm's
hypervisor thread to perform a costly vMMU guestPA->hostVA mapping
(configure a new kvm memslot).
With this change, the entire Virtio-GPU PCI BAR address space can
optionally be pre-configured to a single vMMU mapping. Then, subsequent
RESOURCE_MAP_BLOB requests are handled by mmap() of the blob's exported
fd (dma-buf, shmem, ...) in the hypervisor process to a fixed hostVA
within an unused portion of the vMMU's pre-mapped region corresponding
to the blob's guestPA in the virtio-gpu device's BAR.
The new option is disabled by default, since this is not yet compatible
with the exposure of host dma_bufs to a PCI-passthrough device via
virtio-iommu + vfio. Those features are currently mutually exclusive
(i.e. PCI-Passthrough GPU must continue to use per-blob vMMU mappings
for now).
BUG=b:246334944
TEST=tools/presubmit
TEST=(in linux VM + venus): vkcube
TEST=(in linux VM + virgl): apitrace replay <opengl-game-trace-file>
Change-Id: Ibdd9ad8c12651cb7d31dd8648be9da17cc01cba3
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5255761
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Ryan Neph <ryanneph@google.com>
Make this cause of a failed "fixed mapping" attempt obvious when
inspecting the logs. This shouldn't be seen in production and is here
for developers that attempt to enable an incompatible VmMemorySource
type before it can be supported.
BUG=b:246334944
TEST=tools/presubmit
Change-Id: Ief32abc85d0aa07d4507a1d53f0ba55becca5e0f
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5255759
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Ryan Neph <ryanneph@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Inline a procedure that has only a single caller.
BUG=b:246334944
TEST=tools/presubmit
Change-Id: Ib727090c710162d16bdf4acf05e5b94c0e80e16a
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5255758
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Ryan Neph <ryanneph@google.com>
A device failing to wake up is a pretty generic error. This CL adds the
device's debug label so it's easier to understand which device is
failing.
BUG=None
TEST=builds
Change-Id: I35d67cd356b95f3b4875ae1fe3bf358c0cc329fe
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5271324
Reviewed-by: Elie Kheirallah <khei@google.com>
Commit-Queue: Noah Gold <nkgold@google.com>
On Intel, new noncoherent DMA mem flag can be set to allow KVM to
recognize guest cache setting for EPT, which allows WC attribute to be
applied to ensure guest memory access is synchronized in noncoherent DMA.
Unlike previous POC for new device attribute, this uses new added flag
for mem slot.
BUG=b:316337317
TEST=cargo build and run GPU workload
Change-Id: If16d61031bdb2cf0252a57e99d4b6725a89dd38a
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5171312
Reviewed-by: Frederick Mayle <fmayle@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Stanisław Kardach <skardach@google.com>
Instead of building up one big json value, we pass around a "writer"
object that allows writing out fragments of the snapshot and nested
namespacing. The snapshot fragments can use different serialize formats
if desired, e.g. the RAM snapshot uses a raw binary file.
Snapshot directory contents:
213 .../bus0/ACPIPMResource-0
299 .../bus0/cmos-0
2 .../bus0/i8042-0
542 .../bus0/pci-config-io-port-0
234 .../bus0/serial-0
234 .../bus0/serial-1
234 .../bus0/serial-2
235 .../bus0/serial-3
536 .../bus1/pci-config-mmio-0
3.5K .../bus1/pcivirtio-balloon-0
6.1K .../bus1/pcivirtio-block-0
1.7K .../bus1/pcivirtio-rng-0
536 .../bus1/pci-virtual-config-mmio-0
569 .../bus1/PvPanic-0
5.3K .../irqchip
8.0G .../mem
52 .../mem_metadata
6.5K .../vcpu/vcpu0
6.6K .../vcpu/vcpu1
6.5K .../vcpu/vcpu2
6.5K .../vcpu/vcpu3
For now, the new abstractions are not used in `BusDevice` or any layers
beyond `BusDevice`, so each device is still a monolithic JSON file.
`PciConfigIo::debug_label` was modified so that it can't change at
runtime.
Based on some light testing, this seems to reduce the snapshot time for
a particular ubuntu VM config from 14s to 13s.
BUG=b:268093674
Change-Id: Ic16980629ff9321bee19f56f6e8e50f214492a7d
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4739910
Commit-Queue: Frederick Mayle <fmayle@google.com>
Reviewed-by: Elie Kheirallah <khei@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Noah Gold <nkgold@google.com>
gdbstub 0.6.3 -> 0.7.0
gdbstub_arch 0.2.4 -> 0.3.0
There is small change in API, see src/crosvm/gdb.rs. `read_addrs` now returns a `usize` instead of a `()`.
This change is needed to submit this AOSP topic: https://android-review.git.corp.google.com/c/platform/external/crosvm/+/2879249
BUG=b:286979636
TEST=tools/presubmit --all
Change-Id: I124d65e673c5943070c2bb5e39e3a7e5506e5528
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5146447
Commit-Queue: Frederick Mayle <fmayle@google.com>
Reviewed-by: Vikram Auradkar <auradkar@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
In this case, `recv` returns `Result<Result<(), Error>, RecvError>` and
we only checked the `RecvError` error, actual vCPU restore errors were
ignored.
BUG=b:316912197
TEST=Added `anyhow::bail!` line to the vCPU restore and observed that restoring no longer gets stuck
Change-Id: I51a5e3ff90a9248a7eb5790394143fa0188b2955
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5146882
Reviewed-by: Elie Kheirallah <khei@google.com>
Reviewed-by: Noah Gold <nkgold@google.com>
Commit-Queue: Frederick Mayle <fmayle@google.com>
The TSC itself is saved/restored as a MSR by most hypervisors
(e.g. KVM), so we generally don't need to also save/restore the
TSC offset*; in fact, this could desync TSC and lead to guest time
warping because the TSC offset cannot be set directly (it has to
use a host TSC reference moment). However, some hypervisors need
to use the TSC offset to fix up timekeeping in concert with
virtio-pvclock.
This CL does several things to resolve these issues:
1. Stop always restoring TSC offset.
2. Provide a new method for hypervisors to implement their own
behavior with TSC offset & restoring timekeeping.
3. Take a common host TSC reference moment and provide it to the
timekeeping restore method.
* We later discovered KVM's pvclock seems to not be working correctly if
we stop restoring the TSC offset. It seems that setting TSC_KHZ via
the KVM API somehow fixes the issue as well. Further investigation is
needed to understand why. For the time being we're going to keep the
existing TSC offset restore behavior.
Thanks to colindr@ for a ton of help debugging & understanding the
underlying timekeeping problem and hypervisor oddities.
BUG=b:311314468
TEST=tested on WHPX.
Change-Id: Ib2196085061f57931362b3d5da2383bc5e1abbe7
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5042037
Commit-Queue: Noah Gold <nkgold@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Colin Downs-Razouk <colindr@google.com>
Reviewed-by: Frederick Mayle <fmayle@google.com>
On MacOS there is no MSG_NOSIGNAL, but there is SO_NOSIGPIPE which is
set as a socket option. This changes ScmSocket from a trait to a wrapper
type that can guarantee SO_NOSIGPIPE is set once on every relevant
socket before it is used in situations that can produce signals.
The biggest wrinkle is that setsockopt can produce errors, which makes
the conversion into ScmSocket a case that can possibly error. Not all
places that accept sockets were prepared to return errors.
Bug: b/309020556
Change-Id: I079bbaf8803e137ca7c0e0ebe60e63de5df59cc0
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5021438
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Cody Schuffelen <schuffelen@google.com>
base::Pid is explicitly added since every platform has a process id
type.
Bug: 233233301
Test: tools/dev_container ./tools/presubmit
Change-Id: Id0d54fe06981c1dcbdee3f73b1241af74a26300f
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4909061
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Cody Schuffelen <schuffelen@google.com>
Messages to/from service are multipart - variable length message
follows fixed length header. MultiPartMessage ensures that
(Header, Message) pair is read/written by one call from one thread.
Bug: 269191436
Test: flat run emulator
Change-Id: Icaf43ad99049f2b593aa20462ec1410d2db6b8a1
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4973856
Commit-Queue: Vikram Auradkar <auradkar@google.com>
Reviewed-by: Vikram Auradkar <auradkar@google.com>
Auto-Submit: Kaiyi Li <kaiyili@google.com>
Change bus logs from info to debug.
Add debug logs for each device on sleep, snapshot, wake, restore.
Add info log at top level snapshot and restore.
BUG=N/A
TEST=boot crosvm, snapshot. Shut down, boot with restore.
TEST=boot crosvm with --log-level=debug, snapshot. Shut down, boot with restore.
Change-Id: I67263a5745dac6647dbe689aa3b97c8f43555593
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4954726
Auto-Submit: Elie Kheirallah <khei@google.com>
Reviewed-by: Frederick Mayle <fmayle@google.com>
Commit-Queue: Elie Kheirallah <khei@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Updates are made to source and documentation.
This more accurately represents the currently supported platforms of
Android/Linux and Windows, without unexpectedly including other
unix-like operating systems.
Command to reproduce:
$ find . -type f -not -path '*/\.git/*' | xargs -I {} sed -i 's/cfg(unix)/cfg(any(target_os = "android", target_os = "linux"))/g' {}
$ cargo fmt
md files manually updated to fix line lengths.
Renaming `unix` modules to `linux` will be done in a later CL.
Test: ./tools/dev_container ./tools/presubmit
Bug: b/298269162
Change-Id: I42c1bf0abf80b9a0df25551613910293217c7295
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4909059
Commit-Queue: Cody Schuffelen <schuffelen@google.com>
Reviewed-by: Frederick Mayle <fmayle@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Noah Gold <nkgold@google.com>
We used to cap the guest resolution at 1080p. We are experimenting with
higher resolutions, gated by the feature flag enable_4k_uhd_resolution.
Two places need to change:
1. The virtual display size should be capped at 3840x2160 instead if the
feature is enabled. This size is used as the guest resolution.
2. guest_dpi_manager should provide the recommended DPI for the newly
added resolutions. It is fine not to check the feature flag there
since the BSS knows whether or not to use those values.
get_virtual_display_size() may be called by validate_gpu_config(), which
happens very early and the process variants are not yet written to the
static variable PROCESS_INVARIANTS, so we can't use the macro
phenotype!. As a workaround, we load the process variants and read the
flag by ourselves. In the long term, the BSS should be specifying the
virtual display size when launching KiwiVM, so we should be able to get
rid of This workaround.
Bug: 276352265
Test: Ran GPG with the feature enabled/disabled, and verified that the
resolution is capped at 4k UHD when it is enabled.
Change-Id: I3ec06deda1aa5b7fe89dde5bca426248b93b3ecf
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4804797
Reviewed-by: Vikram Auradkar <auradkar@google.com>
Commit-Queue: Kaiyi Li <kaiyili@google.com>
This CL defines do_net_add/remove with the same function signature when
pci-hotplug feature flag is disabled. This allows crosvm_control to be
unaware of the pci-hotplug flag.
TEST=presubmit tests.
BUG=b:294777126
Change-Id: I4c6a3b96c01ecea9f9f01dcd1c7f65ca042a5664
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4851835
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Ningyuan Wang <ningyuan@google.com>
This CL factors out do_net_remove to vm_control from main.rs.
do_net_remove sends a VmRequest to remove a tap device.
Test= presubmit tests.
Bug=b:294777126
Change-Id: I82e2741a044b1144f04424deacc905fbe079560c
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4846021
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Ningyuan Wang <ningyuan@google.com>
As usual, some unsorted and grouped imports have appeared.
Change-Id: I79b51e4c52cee38f5b8c238e46dfe3193c753554
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4847980
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
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>
crosvm has never actually supported running on a 32-bit x86 host, only
x86-64. Remove the cfg(target_arch = "x86") checks throughout the tree
to make this clear (and to simplify the code).
This doesn't affect the code running inside the guest, which can still
be a 32-bit x86 operating system if launched via --bios, for example.
BUG=None
TEST=tools/dev_container tools/presubmit
Change-Id: Ifd888db54c58ec8a5fcf840871ef564771d9066b
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4794387
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Zihan Chen <zihanchen@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Add the option to wait for a balloon adjustment to successfully
complete. To allow the client to handle failures by re-adjusting the
balloon, this command bypasses the queuing logic in BalloonTube.
This new feature is used by vm_concierge in crrev/c/4744519.
BUG=b:259503518
TEST=cargo test -p vm_control --features balloon
TEST=repeat-test.sh -r 300 -- kohaku arc.Swap
Change-Id: Ib9a990cdfc4001d6294e654776ac0b130ebc94e2
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4744559
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: David Stevens <stevensd@chromium.org>
After integrating downstream, we found a couple of adjustments that were
worth making:
* Bug: get_read_notifier wasn't used on the Tube, so it wouldn't ever
wake up when added to the wait context.
* Feature: an adjust request has no reply, so having to specify a
response id doesn't make sense since we don't actually want the reply
routed anywhere (in some cases, we have no where to route it).
BUG=b:291684465
TEST=builds.
TEST=tested downstream.
Change-Id: Idfb1bd4d28ad26f1df3fd6d543df43cf84938975
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4718769
Commit-Queue: Noah Gold <nkgold@google.com>
Reviewed-by: David Stevens <stevensd@chromium.org>
This CL implements PCI hotplug feature for virtio-net device. The
feature is controlled by pci-hotplug feature flag and pci-hotplug-slots
runtime flag. No behavior change to crosvm unless pci-hotplug-slots flag
is set to a nonzero value.
BUG=b:243767476
TEST=tools/presubmit
TEST=e2e_test::tap_hotplug for TAP device hotplug and removal
TEST=manual test for TAP device hotplug and removal with swap
Change-Id: I5a60314293ef8a27981d7b550a61822491c254bb
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4473610
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Shin Kawamura <kawasin@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Ningyuan Wang <ningyuan@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Jason Iman <jasongustaman@chromium.org>
