Basic implementation of fw_cfg device. The device is recognized by
OVMF, and OVMF can read a hard-coded number 0x66 from the device with fw_cfg's read(). Arbitary files can be written to the device via FwcfgDevice::add_file(). The device is activated with the command line param --fw-cfg. Specifying --fw-cfg alone will activate the device
and additional arguments may be specified so that a user-specified data blob may be added from the command line. Currently, however, attempting to add a data blob from the command line is a noop.Still need to implement read() and write().
BUG=b:283990685
Change-Id: Iec899b7568b7f9195084c5cbcde1fc8a8fafd9fa
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4659945
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Sebastian Hereu <sebastianhereu@google.com>
Some downstreams currently still use the legacy console. Some e2e_tests
(snapshot/restore) also will require using the legacy console, as the
AsyncConsole does not currently have an implementation for these
functions.
BUG=N/A
TEST=presubmit
TEST=run VM with legacy console flag
Change-Id: I97f94d79c6b0c2c23115283e1539f7cda580f5b8
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4618965
Reviewed-by: Noah Gold <nkgold@google.com>
Reviewed-by: Frederick Mayle <fmayle@google.com>
Commit-Queue: Elie Kheirallah <khei@google.com>
Rather than just printing an error and continuing, this makes the errors
fatal when adding a PCI device with invalid configuration (e.g. an
address on the wrong bus) at startup time. Hotplug errors are still
considered non-fatal and execution continues in that case.
BUG=None
TEST=crosvm run --stub-pci-device 2:00.0,...
Change-Id: Ia831cc1fc1ca1f04ad7e45dba5978671157a51b4
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4583465
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Ningyuan Wang <ningyuan@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
When a hot plug device is detached, its uffd becomes dead. This commit
adds a garbage collector to remove dead uffds and prevent the uffd list
and obsolete opened file descriptors from growing indefinitely.
BUG=b:267124393
BUG=b:281791015
BUG=b:266898615
TEST=https://crrev.com/c/4562369
Change-Id: I11d3298b8e4838bbb843e4dc10f29f32a02b0646
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4525480
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Shin Kawamura <kawasin@google.com>
Add snapshot/restore to irqchip for kvm and whpx to save the state of the irqchip.
Add saving apic_base as part of the irqchip.
BUG=b:266515147
BUG=b:232437513
Test=crosvm build - testing requires more changes related to VmRunnableLinux
Change-Id: Iffbd38634390d276d70d6467549df9ffaf176059
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4518572
Commit-Queue: Elie Kheirallah <khei@google.com>
Reviewed-by: Noah Gold <nkgold@google.com>
Reviewed-by: Frederick Mayle <fmayle@google.com>
Auto-Submit: Elie Kheirallah <khei@google.com>
This was used in crosvm-direct to read the host SMBIOS tables and
provide them to the guest. Clean up the dead code.
BUG=b:279218487
TEST=tools/dev_container tools/presubmit
Change-Id: I7c6c69f90ffbcbcc1331e37392bac6926c0edd33
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4539924
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Introduce support for a virtual CPU frequency device
to improve guest task placement behaviour along with performance
and power usage of workloads within VMs[1]. This device adds MMIO regions
that enables the guest to:
- Query for the frequency of the physical CPU that the current
vCPU is affined to.
- Send frequency requests that can be used as hint for the
host to schedule vCPU threads and choose physical CPU frequency.
Add a config option "--virt-cpufreq" that enables the virtual cpu device
and populates the frequencies of vCPUs through devicetree, which can
be used by a guest kernel cpufreq driver[2].
[1] https://lore.kernel.org/all/20230330224348.1006691-1-davidai@google.com/
[2] https://android-review.git.corp.google.com/c/kernel/common/+/2239182
Bug: None
Test: ./tools/presubmit
Change-Id: I03983c5e4a3fa288ca19504aa093ad1f7f9f7e51
Signed-off-by: David Dai <davidai@google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4504738
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Devices now handle ioevent registration dynamically, which makes
ioevents compatible with BAR reprogramming, so we can remove the
PciDevice trait function and its callers.
Change-Id: Ic178c48e585b24a56f017d824602f6856f6b40a6
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4500898
Reviewed-by: Zihan Chen <zihanchen@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Adding Victual PMC device allows to trap on MMIO access caused by its
Linux driver counterpart upon entering s2idle state. Linux Virtual PMC
driver registers notify() hook, which is triggered before system
actually enters s2idle state and triggers _DSM method which in turn
triggers MMIO access causing mentioned trap.
More info can be found in relevant linux kernel mailing list thread which
implements kernel counterpart:
https://patchwork.kernel.org/project/linux-pm/patch/20230213100921.268770-2-jaz@semihalf.com/
Upon Virtual PMC BusDevice write() handling, trigger functionality
responsible for handling s2idle notification, which is: wakeup blocked
thread awaiting guest suspension to finish.
Old functionality for handling s2idle request based on non-accepted by
Linux community, hypercall based solution - is removed as separate patch
CL:4507305
BUG=b:194391015
TEST=Make sure that S2Idle notification from guest are seen by crosvm
when --s2idle parameter is used. In such case the guest suspension is
detected quite fast and 15s timeout is not reached.
Change-Id: I79e1755cd344c46e7fa0dabc211cf7e354583204
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3780642
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Grzegorz Jaszczyk <jaszczyk@google.com>
To more accurately model the underlying hardware, add dynamic power
coefficient as a parameter to pass from the host OS to the guest OS.
This gives an indication to the guest OS about which CPUs and which
clusters of CPUs are more efficient.
Add a config option "--dynamic-power-coefficient" that allows the power
coefficients of individual CPUs on the guest to be customized at a more
granular level. The new parameter is a scalar coefficient for
calculating power.
See Documentation/devicetree/bindings/arm/cpus.yaml for more info
Bug: b:280358794
Test: ./tools/presubmit passes; Verified new parameters show up when
running crosvm
Change-Id: I0246adcb893546a88a292fcfe9ff40fb08411b10
Signed-off-by: Sam Wu <wusamuel@google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4497380
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: David Dai <davidai@google.com>
Remove the architecture-specific requirements from the gdb config
checks. This enables gdb across every supported target_arch without
having to manually add new architectures to each cfg check.
For the specific case of target_arch = "arm", this patch will newly
enable gdb support. The gdbstub protocol will still send aarch64 state,
matching the guest.
This stubs out enough riscv64 gdb functions and types to make
`cargo build --features=gdb` compile, but gdb support will not be
functional on that architecture without additional work.
Change-Id: I63b079b7a3dca4aec2c13c775c0ccb8850625884
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4506285
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Dylan Reid <dgreid@rivosinc.com>
Status does not depend on any swap related feature. Exposing Status to
all variants is easy to implement swap status FFI at crosvm_control.
The new "swap/enable" feature switches the actual vmm-swap functionality
to be compiled. The feature is enabled by default on "swap" crate but
disabled on the root package for test dependency.
Vmm-swap feature is enabled by `--features=swap` flag on cargo build as
before.
swap/src/controller.rs is copied from swap/src/lib.rs.
BUG=b:265386761
TEST=tools/dev_container tools/run_tests2
Change-Id: Ifc2539a62d0f594fd5bbb41623c735ea2621f7b6
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4486546
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Shin Kawamura <kawasin@google.com>
Reviewed-by: David Stevens <stevensd@chromium.org>
Also use the arch definitions in the main crosvm crate to avoid
duplicating the cfg checks.
BUG=None
TEST=tools/dev_container tools/presubmit
Change-Id: Ia92b2840b0f6c8f0daa25f4b2b185ef7ef372860
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4477764
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Noah Gold <nkgold@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
This imports the basics that are needed and closely mirrors x86 and arm.
Change-Id: Ia7894166092bccf1ff13dd2e1c8fb17e0d2acca3
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4460937
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
This is a reland of commit 42a437de5e
This change fixes a crash that occurs when no-rtc is set by properly
checking the Option that can contain the cmos's control tube, instead of
just calling unwrap. It also replaces an unwrap during cmos
initialization with proper error propagation.
Original change's description:
> devices: cmos: implement rtc alarm
>
> Implement CMOS alarm functionality. This allows guests to set rtc
> alarms, which is useful when putting a Linux guest into s2idle.
>
> This change allocates a dedicated interrupt for the goldfish battery,
> instead of reusing the sci irq. Sharing an irq line between a wakeup
> interrupt and a non-wakeup interrupt doesn't work well because the
> non-wakeup interrupt won't be delivered to its driver while the driver
> is suspended, which results in the irq being permanently asserted.
> Simply using a dedicated interrupt for the goldfish battery is much
> easier than adding suspend/resume support to the Linux driver.
>
> BUG=None
> TEST=cargo test -p devices cmos, manual tests w/rtcwake
>
> Change-Id: I757acc64b61e414d5d9df5a1fb4770943ef985bf
> Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4314184
> Reviewed-by: Elie Kheirallah <khei@google.com>
> Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
> Commit-Queue: David Stevens <stevensd@chromium.org>
BUG=None
TEST=cargo test -p devices cmos, manual tests w/rtcwake and no-rtc
Change-Id: Iec73c0aa08b4f2081c3b7a824254723ea9da5365
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4364558
Reviewed-by: Elie Kheirallah <khei@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: David Stevens <stevensd@chromium.org>
Auto-Submit: David Stevens <stevensd@chromium.org>
Add an option to dump the crosvm-generated devicetree blob. This option
can be helpful in understanding what devices are reported to the guest
VM and help diagnose issues related to improper devicetree.
Bug: 249043819
Change-Id: Id18ddf0838520c84f648ed8584db2ef8235ed636
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
(cherry picked from commit 7acecab0b1d4f0428b71823f0e2982d385213279)
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4346951
Commit-Queue: Steven Moreland <smoreland@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Simple rename to emphasize that vcpu_ids are not KVM-specific.
(cherry picked from commit 4450ecc21609191210065c5acb5fa1c6f1ad1daf)
Change-Id: I4e702338d8aa1260f9205b19db3eced48661be01
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4346942
Reviewed-by: Dennis Kempin <denniskempin@google.com>
This reverts commit 42a437de5e.
Reason for revert: This is crashing if no_rtc is set (http://go/bbid/8787052669966742145/test-results)
Original change's description:
> devices: cmos: implement rtc alarm
>
> Implement CMOS alarm functionality. This allows guests to set rtc
> alarms, which is useful when putting a Linux guest into s2idle.
>
> This change allocates a dedicated interrupt for the goldfish battery,
> instead of reusing the sci irq. Sharing an irq line between a wakeup
> interrupt and a non-wakeup interrupt doesn't work well because the
> non-wakeup interrupt won't be delivered to its driver while the driver
> is suspended, which results in the irq being permanently asserted.
> Simply using a dedicated interrupt for the goldfish battery is much
> easier than adding suspend/resume support to the Linux driver.
>
> BUG=None
> TEST=cargo test -p devices cmos, manual tests w/rtcwake
>
> Change-Id: I757acc64b61e414d5d9df5a1fb4770943ef985bf
> Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4314184
> Reviewed-by: Elie Kheirallah <khei@google.com>
> Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
> Commit-Queue: David Stevens <stevensd@chromium.org>
Bug: None
Change-Id: I25737095f84ca0b56d94924a9d8ccb5fd42ff51c
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4329909
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Implement CMOS alarm functionality. This allows guests to set rtc
alarms, which is useful when putting a Linux guest into s2idle.
This change allocates a dedicated interrupt for the goldfish battery,
instead of reusing the sci irq. Sharing an irq line between a wakeup
interrupt and a non-wakeup interrupt doesn't work well because the
non-wakeup interrupt won't be delivered to its driver while the driver
is suspended, which results in the irq being permanently asserted.
Simply using a dedicated interrupt for the goldfish battery is much
easier than adding suspend/resume support to the Linux driver.
BUG=None
TEST=cargo test -p devices cmos, manual tests w/rtcwake
Change-Id: I757acc64b61e414d5d9df5a1fb4770943ef985bf
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4314184
Reviewed-by: Elie Kheirallah <khei@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: David Stevens <stevensd@chromium.org>
Creates the jail create and move all policy files and helper methods to
the crate to make jail helpers available to outside of the main crate
(i.e. swap crate).
This also move devices::Minijail and JailConfig to jail crate.
BUG=b:258351526
TEST=cargo build
Change-Id: If9a148bdb3b18f8b746875d47d1077fb17707c18
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4230456
Commit-Queue: Shin Kawamura <kawasin@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Noah Gold <nkgold@google.com>
Reviewed-by: David Stevens <stevensd@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
This commit introduces ACPI0003 emulated device, which can be enabled by
passing "--ac-adapter" argument.
Emulating ac adapter allows to replicate ac adapter state on the guest side.
The host kernel already propagates ac adapter status to user-space by
generating acpi events: acpi_bus_generate_netlink_event so crosvm upon
receiving "ac_adapter" class acpi event, stores the corresponding data
(ac status) into ac register. Next the previously allocated GPE is
triggered to inform the guest about status change.
Guest upon handling GPE, thanks to generated aml code:
Device (ACDC)
{
Name (_HID, "ACPI0003" /* Power Source Device */) // _HID: Hardware ID
OperationRegion (VREG, SystemMemory, 0x0000000220E00010, 0x10)
Field (VREG, DWordAcc, Lock, Preserve)
{
ACEX, 32
}
Method (_PSR, 0, NotSerialized) // _PSR: Power Source
{
Return (ACEX) /* \ACDC.ACEX */
}
Method (_STA, 0, NotSerialized) // _STA: Status
{
Return (0x0F)
}
}
Scope (_GPE)
{
Method (_E00, 0, NotSerialized) // _Exx: Edge-Triggered GPE, xx=0x00-0xFF
{
Notify (ACDC, 0x80) // Status Change
}
}
triggers Notify on AC adapter and therefore replicates the host
ac_adapter state (accessing ACEX pointed by opregion results with trap
to crosvm, which returns previously stored ac status).
BUG=b:244205651
TEST=Plug/Unplug AC adapter and inside guest run:
1) acpi_listener and confirm that proper acpi events are replicated
2) observe: `cat /sys/class/power_supply/ACDC/online`
Change-Id: I9b1045cfcae1c4de48a0ad50f63148cfe9ff226b
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4186657
Auto-Submit: Grzegorz Jaszczyk <jaszczyk@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Grzegorz Jaszczyk <jaszczyk@google.com>
This implements the equivalent logic on crosvm as
UFFD_FEATURE_EVENT_FORK. When each device process forks, the ProxyDevice
creates userfaultfd and send it to the monitor process by
SwapController::on_process_forked().
Crosvm does not have any child processes which may access the guest
memory except device processes as of now. Crosvm forks
virgl_render_server, but the mmap is not preserved in the process on
execve(2) since it is a different binary. Also no device process forks
grandchild processes according to the seccomp policy.
We actually can't use UFFD_FEATURE_EVENT_FORK because the feature does
not support non-root user namespace (go/uffd-fork-user-ns) and ARCVM
runs in a non-root user namespace.
This also adds syscalls to seccomp policies for devices to allow the
processes to create and setup a userfaultfd.
BUG=b:266641923
TEST=manually tested
Change-Id: Ide3088e1e95ae3c8259e3f4324124b3376e760b7
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4194228
Reviewed-by: David Stevens <stevensd@chromium.org>
Commit-Queue: Shin Kawamura <kawasin@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Adds a new hypervisor capability that causes crosvm to statically
allocate the location of the swiotlb buffer.
This will be used by the gunyah hypervisor.
BUG=b:244630071,b:232360323
Change-Id: Ia2f379bb6f2fa89167ddc73d65ec1b8c5494bdf6
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4197001
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Vikram Auradkar <auradkar@google.com>
Commit-Queue: Frederick Mayle <fmayle@google.com>
No behavior change intended.
We'd like to make some aspects of the guest memory layout dependent on
hypervisor capabilities in future commits.
Note for x86_64: `Arch::guest_memory_layout` initializes some global
state so some care is needed when moving it relative to other code. In
this case it is safe because the only code being moved before
`Arch::guest_memory_layout` is `get_default_hypervisor`, which is
currently a constant, and `Kvm::new_with_path`, which just performs an
`open` syscall and wraps it in a `Kvm` struct. Neither depend on the
x86_64 specific global state.
BUG=b:232360323,b:244630071
Change-Id: I8bf70bb18e56dd7e7ac78c615fdb9877a87b66c4
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4197000
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Vaibhav Nagarnaik <vnagarnaik@google.com>
Add an option to dump the crosvm-generated devicetree blob. This option
can be helpful in understanding what devices are reported to the guest
VM and help diagnose issues related to improper devicetree.
Bug: 249043819
Change-Id: Ic6cfe9c12cc01d7aaa66c193b027e1f66d8a02b3
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4174623
Commit-Queue: Frederick Mayle <fmayle@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
The PowerMonitor trait and the code monitoring it for events is not
platform specific, so it can be moved out of sys/unix into the main
battery code.
BUG=b:213149155
TEST=tools/presubmit --all
TEST=emerge-brya crosvm
Change-Id: I5c34c0e98009d866d5345fd940ecc7f742da1d2c
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4122803
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
These should be written as ChromeOS and ChromiumOS (without the space)
to match the updated branding. The copyright headers were already
migrated to the new style (https://crrev.com/c/3894243), but there were
some more instances left over.
BUG=None
TEST=tools/cargo-doc
Change-Id: I8c76aea2eb33b2e370ab71ee9b5cc0a4cfd00585
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4129934
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@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>
Add snapshot functionality in Bus.
Add thread to handle communication between VM cmdline and devices.
Add DeviceCommandControl in vm_control to handle device-specific
actions.
Bug=b:232437513
Test=cargo build && cargo run ...
Change-Id: If3795c9e1f12ab4cd34ab36cad8eae43d469a50a
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3930627
Auto-Submit: Elie Kheirallah <khei@google.com>
Commit-Queue: Elie Kheirallah <khei@google.com>
Reviewed-by: Frederick Mayle <fmayle@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Steven Moreland <smoreland@google.com>
For convenience, a set of CPU cores can be specified as a sequence of
elements which can be either a single integer, or a string of the form
"start-end" in order to specify a range.
This will allow us to create CPU clusters from the `--cpu` parameter or
from the JSON configuration file in a future CL.
BUG=b:255223604
TEST=cargo test
Change-Id: I55675fcb8645fea1fe59540cb6f2affb900edc50
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4060600
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
We are using Vec<usize> as a way to represent sets of CPU cores for
things like CPU clusters, which is not very verbose as to what the
vector is for without context and forces us to separate things like
parsing of CPU clusters into separate, independent functions.
Replace these vectors by a proper CpuSet struct, with its own
implementation of FromStr. We will then extend it with
serialization/deserialization ability to improve argument parsing.
BUG=b:255223604
TEST=cargo test
Change-Id: Ibb954a41bcedc088e2eb07b5157343344f3ad40b
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4060286
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
This removes the last caller of parse_key_value_options().
BUG=b:255223604
TEST=cargo test
Change-Id: Ia17eb320094ee3d46f0db238f2077163e257b7f8
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4049037
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
As part of commit cadc84b32a the crosvm
suspend command has been extended to generating sleep button injection
in order to put VM in suspend state. Additionally the crosvm suspend
command completed after the guest entered proper power state.
Nevertheless in some circumstances above implementation caused issues.
E.g. when the guest with pass-through devices entered run-time device
suspension, triggering a subsequent system suspend request fails and
makes VM inaccessible. It is because before entering system suspension,
devices which entered device run-time suspension needs to be resumed.
Therefore in problematic scenario:
- VmRequest::Suspend was triggered and it resulted with blocking till
guest entered proper suspend state
- during VM suspension process some pci config write accesses are made,
which in some cases triggers write_msi_reg-> write_msi_capability->
add_msi_route, which underneath sends VmIrqRequest::AddMsiRoute
request
- above VmIrqRequest::AddMsiRoute request can't be satisfied since
VmRequest::Suspend made the run_control wait loop busy waiting and
preventing further requests to be processed
In order to fix the above issue, instead of busy waiting directly in the
run_control wait loop for suspend notification, spawn a new thread, which
will generate the acpi power button and start busy waiting for a
notification that the VM actually entered suspend state. This allows to
postpone sending response over the control tube indicating that the
'crosvm suspend ...' command completed and in the same time process
other Vm*Requests.
Mentioned postponement of 'crosvm suspend ..' completion is crucial
since the full system suspension needs to be blocked till VM actually
enters proper suspend state.
BUG=b:248462336
TEST=With a setup where some device is pass-through to the VM and
--force-s2idle flag is used: wait till pass-through device enters
run-time suspend state and trigger "crosvm suspend
/run/vm/vm.<hash>/crosvm.sock" followed by "crosvm resume ..". Also make
sure that full system suspension/resumption doesn't make VM inaccessible
anymore.
Change-Id: Ic23461a78a62d2116cf5674c71d89f4f86ad96c3
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3944915
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Grzegorz Jaszczyk <jaszczyk@google.com>
Reviewed-by: Noah Gold <nkgold@google.com>
Don't cause compile error when the `gdb` feature is specified on
unsupported platform (e.g. armhf). Instead, do nothing
when it's specified.
Also, enable "gdb" feature in all-armhf feature so it's tested in CI.
Note that this change is a follow-up of
https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4011747/comment/973cd5d8_02e5a2f7/
BUG=none
TEST=run_tests --platform=armhf with "gdb" feature enabled
Change-Id: I06fc2e428c3595eb01c7172759945aa4a3159e8a
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4015999
Auto-Submit: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
We had a manual parsing function that is strictly equivalent to how
serde_keyvalue would deserialize, so do the latter instead.
Also add some tests to make sure we don't regress in the future.
BUG=b:218223240
TEST=./tools/health-check
Change-Id: I5b6317774368fa4256a1944e7aec54e8fe8f210a
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3979494
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
This will let the hypervisor crate use types and functions from the new
cros_fdt crate (it could not depend on arch, since that would cause a
circular dependency).
No functional change, just code movement.
BUG=b:253416076
TEST=cargo build
TEST=cargo build --target=aarch64-unknown-linux-gnu
Change-Id: I62d906941867c45f1b77ff1db6923d915ce2123e
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3965088
Reviewed-by: Steven Moreland <smoreland@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Add the infrastructre for GDB 'p'/'P' packets, used by the client to get
or set individual registers.
Implement a back-end using KVM_{G,S}ET_ONE_REG on AArch64, enabling the
client to access the architecture's numerous system registers.
Add stubs for x86 to please the compiler; leave them unimplemented as,
although the ioctl is available, the architecture doesn't seem to make
use of it.
BUG=b:222222882
BUG=b:240711627
BUG=chromium:1141812
TEST=tools/dev_container ./tools/run_tests
Change-Id: I01968275e88e9d0098de40b3f78e2cd3a61b75da
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3785468
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
This search/replace updates all copyright notices to drop the
"All rights reserved", Use "ChromiumOS" instead of "Chromium OS"
and drops the trailing dots.
This fulfills the request from legal and unifies our notices.
./tools/health-check has been updated to only accept this style.
BUG=b:246579983
TEST=./tools/health-check
Change-Id: I87a80701dc651f1baf4820e5cc42469d7c5f5bf7
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3894243
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
We are going to need to start passing a new arch-dependent configuration
parameter to KvmVm::new in addition to protection_type. Since we can't
[cfg] a function argument, and to avoid churning the tests the next time
we need another argument, let's create a hypervisor::Config struct and
start passing protection_type that way.
Bug: b:234779841
Change-Id: I42ce9438b064658ebb9732e78ee5c82dac2636b6
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3892140
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Peter Collingbourne <pcc@chromium.org>
Type 11 SMBIOS OEM strings entries are commonly used to pass arbitrary
information into a VM. For example, systemd's credentials[1] system
looks for specially formatted values here.
The main goal here is to allow parameterization of a VM when we're
booting with OVMF, in which case providing parameters via the kernel
cmdline is less useful.
QEMU suports something similar, but this is a significantly simplified
approach, allowing only OEM strings instead of a wider range of DMI
table entries QEMU allows customizing.
[1]: https://systemd.io/CREDENTIALS/
BUG=b:244366989
TEST=cargo test; passed oem strings into vm and confirmed they are in
dmi tables
Change-Id: I5e106983e624c8a244b8074d6944bc0c9acfd748
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3868327
Auto-Submit: Mike Gerow <gerow@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Mike Gerow <gerow@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
