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>
The new rust toolchain comes with improved clippy warnings that
catch more unnecessary casts than before.
Some cases have to be whitelisted since libc types have varying size
based on the architecture we are compiling for.
BUG=None
TEST=presubmit
Change-Id: Ia473b0bfe6e74bdb7b0d4ca15d2c9fb410fc353e
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4568144
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
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>
VcpuRunHandle was only used to signal immediate_exit on unix platforms;
it was unnecessary on Windows. It is replaced with a new
VcpuSignalHandle abstraction that is only implemented for cfg(unix).
This commit moves the thread local storage out of hypervisor and into
the unix/vcpu.rs code; it does not need to be duplicated in each
hypervisor backend.
BUG=b:281723434
TEST=boot crosvm on Linux and Windows
Change-Id: I99491aa3509d86623521298bdcbe5eb9dfcd2d8b
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4382340
Reviewed-by: Noah Gold <nkgold@google.com>
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>
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>
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>
To prevent accidentally ACPI FACP overwriting similar to one described
in the b:279563028 add unit test which will catch such bugs in the
future.
BUG=b:279563028
TEST=tools/run_tests
Change-Id: Ie1dac4460b1ce7c9186835dbbbaa3f6001fabaa1
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4482091
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Grzegorz Jaszczyk <jaszczyk@google.com>
According to ACPI specification the RTC's DAY_ALRM, MON_ALRM and CENTURY
are all 8-bits values. Fix the related register sizes in order to
prevent other ACPI FADT fields overwriting happen e.g. in
x86_64/src/acpi.rs:
facp.write(FADT_FIELD_RTC_CENTURY, devices::cmos::RTC_REG_CENTURY);
While introducing this change, convert other RTC_REG* consts to u8.
This commit fixes CL:4364558 which accidentally causes some other ACPI FADT
overwriting e.g. FADT FLAGS which introduced regression in borealis project.
BUG=b:279563028
TEST=Run borealis VM and make sure that rendering issues after
suspend/resume cycle are gone.
Change-Id: I159ba16616f0eb08b5fc562e88d2887836815c44
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4477066
Commit-Queue: Grzegorz Jaszczyk <jaszczyk@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
The CpuIdContext code that sets up the tsc_frequency field already
checks for the two conditions where cpuid leaf 0x15 should be replaced
by the calibrated value, so we do not need to repeat these checks at
runtime; just use the state of the variable (if it is Some(tsc) then we
should override the TSC value).
Additionally, clean up the fake_tsc_frequency_cpuid() function to return
the CpuidResult directly; the outer CpuIdEntry was never actually used.
BUG=None
TEST=tools/dev_container tools/presubmit
TEST=crosvm run --force-calibrated-tsc-leaf ...
Change-Id: Iaa9fde721561dfbd6d3871ac73bb0b7e8c589ae4
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4370842
Reviewed-by: Zihan Chen <zihanchen@google.com>
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>
Currently crosvm's boot time on x86 is heavily impacted by TSC
calibration, especially on nested-virtualization environment.
TEST=pending
Change-Id: Iadb0b35185172a3e10d5435ff0c8030cf18004d2
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4326893
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Zihan Chen <zihanchen@google.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>
The issue that caused the revert has been fixed by commit 64065f6b213a
("cros_fdt: remove max_size from FdtWriter::finish()"). The FDT was
padded to a size larger than the available setup_data space on x86-64,
which caused startup to fail any time the --android-fstab option was
used.
Original commit message:
> This moves the setup_data out of the way of the bzImage decompression
> stub, so it won't get overwritten.
>
> Fixes a regression with some kernel configurations introduced in commit
> 5bedfa3408 ("x86_64: add SETUP_RNG_SEED setup_data entry"), which
> unconditionally adds a setup_data entry.
>
> BUG=b:268397895
> TEST=boot x86-64 bzImage in crosvm that previously failed
> TEST=cargo test -p x86_64
This reverts commit a0d14ce819.
BUG=b:268397895
TEST=Start ARCVM on x86-64
TEST=Start Crostini on arm
Change-Id: I41f14578673ea00d1453841dd7cb2438a0a13355
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4277062
Reviewed-by: Shin Kawamura <kawasin@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Rather than checking the maximum size inside FdtWriter, just return the
full Vec<u8> that has already been generated and let the caller do the
check. Additionally, finish() previously always padded the Vec up to the
provided max_size, so the caller could not determine how much fdt space
was actually used; after this change, the padding is removed, so the
caller can observe how much space was actually used.
BUG=b:268397895
TEST=cargo test -p cros_fdt
TEST=Boot Crostini on arm
TEST=Boot ARCVM on x86_64
Change-Id: Ifd7d30581c7afffb09373ce9c34e4d7f9fe0d2b5
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4277061
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
This reverts commit e5aec1e53d.
Reason for revert: The android fstab which is capped limited up to `X86_64_FDT_MAX_SIZE` exceeds the `SETUP_DATA_END` at least on an octopus DUT.
Original change's description:
> x86_64: place setup_data immediately after cmdline
>
> This moves the setup_data out of the way of the bzImage decompression
> stub, so it won't get overwritten.
>
> Fixes a regression with some kernel configurations introduced in commit
> 5bedfa3408 ("x86_64: add SETUP_RNG_SEED setup_data entry"), which
> unconditionally adds a setup_data entry.
>
> BUG=b:268397895
> TEST=boot x86-64 bzImage in crosvm that previously failed
> TEST=cargo test -p x86_64
>
> Change-Id: Ie5efc19d607aad16c1ca80bcdd2fb62933dd73e1
> Fixes: 5bedfa3408 ("x86_64: add SETUP_RNG_SEED setup_data entry")
> Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4233967
> Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
> Reviewed-by: Dmitrii Osipenko <dmitry.osipenko@collabora.corp-partner.google.com>
> Reviewed-by: Zihan Chen <zihanchen@google.com>
Bug: b:268397895
Change-Id: Ie430caa38b745cb1d5e69ac644a2c76813069221
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4272810
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
This moves the setup_data out of the way of the bzImage decompression
stub, so it won't get overwritten.
Fixes a regression with some kernel configurations introduced in commit
5bedfa3408 ("x86_64: add SETUP_RNG_SEED setup_data entry"), which
unconditionally adds a setup_data entry.
BUG=b:268397895
TEST=boot x86-64 bzImage in crosvm that previously failed
TEST=cargo test -p x86_64
Change-Id: Ie5efc19d607aad16c1ca80bcdd2fb62933dd73e1
Fixes: 5bedfa3408 ("x86_64: add SETUP_RNG_SEED setup_data entry")
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4233967
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Dmitrii Osipenko <dmitry.osipenko@collabora.corp-partner.google.com>
Reviewed-by: Zihan Chen <zihanchen@google.com>
This is the limit used by Linux kernels since the 2.6 era, as reported
in the bzImage header as well as the COMMAND_LINE_SIZE definition in
setup.h.
The previous allocation of almost 2 MB was excessive and would have
also overlapped the memory region used for ACPI tables had a long
enough command line been provided.
We will use the area freed up by this change for the setup_data in the
next change.
BUG=b:268397895
TEST=boot x86-64 bzImage in crosvm
Change-Id: I3b5a3771549c3352e609a9685f591be38ae9fa63
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4233966
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Zihan Chen <zihanchen@google.com>
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>
The crosvm kernel loader failed to set the high 32 bits of the command
line address, so it would use whatever value was originally loaded from
the bzImage header. Set the ext_cmd_line_ptr to the high 32 bits of the
address where crosvm loads the command line (usually 0) so the kernel
can correctly locate the cmdline in guest memory.
This fixes booting kernels with CONFIG_X86_5LEVEL=y enabled. The 5-level
paging code checks for the "no5lvl" option in early boot using the
cmdline_find_option_bool() function, which eventually calls the
get_cmd_line_ptr() function and builds a command line pointer by
combining cmd_line_ptr and ext_cmd_line_ptr. Without this patch, this
will potentially access data outside of guest memory and crash.
BUG=b:269162598
TEST=boot x86-64 Linux with CONFIG_X86_5LEVEL=y in crosvm
Change-Id: Ic59a3143529333e21ba2c37c45967314cbb0f1f5
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4246699
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
With the previous CLs migrating many functions and types to use
zerocopy, finally we can do a big clean up of`unsafe impl DataInit`.
We are down to 93 instances now from 230 at 5th CL in this series.
Also fixes a bug introduced previously in this series where I set
the trait bound of a few write_at_addr unsafe functions to
`FromBytes` when `AsBytes` should also be required.
TEST=CQ
BUG=b:204409584
Change-Id: I6658dd246a8932493ef6a652054a23ecfde76198
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4237765
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Zihan Chen <zihanchen@google.com>
SMBIOS data strucutures are defined by a spec, and repr(packed)
allows rustc to reorder items in such structs.
There should be no remaining repr(packed) (usually isn't useful
besides saving memory) in this module after this CL.
TEST=CQ
Change-Id: I6293b238be147a86b975f1fc5fecbb6732479a6d
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4234059
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Zihan Chen <zihanchen@google.com>
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>
Thie effort is splitted into multiple CLs, to reduce change size
and also make bisecing breakages easier.
TESTED=CQ only
BUG=b:204409584
Change-Id: Ie90f171bd5f74b732df3129e94733f3b34621092
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4210751
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Zihan Chen <zihanchen@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>
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>
Add a new configure option in CpuConfigX86_64, and use this option to
set hybrid flags in CPUID for vCPU.
The flags include:
1. CPUID.07H.0H:EDX.Hybrid[bit 15];
2. The Atom/Core type flags in CPUID.1AH.EAX.
Co-Developed-by: Zhuocheng Ding <zhuocheng.ding@intel.com>
BUG=b:255908920
TEST=presubmit
Change-Id: I33663b56fd201221c5fa3557f80d1f5ec5a31c03
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4020038
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Vikram Auradkar <auradkar@google.com>
This helper is used to check the hybrid support on host's CPU:
1. Check if CPUID.07H.0H:EDX.Hybrid[bit 15] is 1.
2. Check if CPUID has basic leaf 1AH.
All these checks are true, then we can confirm host supports hybrid.
Co-Developed-by: Zhuocheng Ding <zhuocheng.ding@intel.com>
BUG=b:255908920
TEST=presubmit
Change-Id: Ie839320154d8955115d79f6f3012f326bd8d1697
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4020037
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
This provides the kernel with an early source of entropy for its random
number generator.
The kernel supports for this was added in commit 68b8e9713c8e
("x86/setup: Use rng seeds from setup_data"):
<https://lore.kernel.org/all/20220710172921.51545-1-Jason@zx2c4.com/>
Earlier kernels will ignore the unknown setup_data entry.
BUG=b:265031416
TEST=Boot x86-64 Linux bzImage with added printk in rng seed init
Change-Id: I627aa8663bd61b04ca311d4d095e1c121fda8543
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3855344
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
The Linux x86 boot protocol setup_data field points to a linked list of
entries; the previous code only supported a single entry and mixed the
implementation into the Android devicetree generation code. Split out
the code that writes setup_data into GuestMemory as write_setup_data()
to simplify the FDT generation code and to support additional entries in
the setup_data list.
BUG=b:265031416
TEST=cargo test -p x86_64
TEST=Boot x86_64 Linux bzImage
Change-Id: Ic7aca66bfcb0168990e4e5ab453d0d4af7f6bdb8
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3855343
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
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>
CrosVM supports PME and hence the PME bit in _OSC should be set.
BUG=b:241526471
TEST=Dump DSDT and verify
Change-Id: Ibc2cbec7096f7025724176834a9ae84c2ab18f04
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4105336
Auto-Submit: Victor Ding <victording@chromium.org>
Commit-Queue: Victor Ding <victording@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
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>
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>
