Currently, crosvm running with --bios <OVMF executable> will only boot
from available block devices if started with a clean BIOS pflash. If
crosvm is not run with a clean pflash, OVMF will get confused and refuse
to boot. The reason for this behavior is that OVMF expects a "bootorder"
file to be present in the fw_cfg device to calibrate its boot order.
This CL allows fw_cfg to specify bootorder, solving the inconsistent
booting behavior. Boot order is specified from the command line with the
bootindex=NUM argument.The bootindex argument is available for block
devices specified with the --block flag. Note that the --fw-cfg flag
must be specified w/ at least on file (can be an empty file with a
random name) on the command line for fw_cfg to actually be made
available to the guest. Also, further investigation is needed if we wish
to boot from pmem devices in the future. See crosvm run -h for more
information about the bootindex argument.
BUG=b:243051819
Change-Id: Ieae1e2cacc14c018832b228db898884281c38a96
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4755415
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Sebastian Hereu <sebastianhereu@google.com>
The newest chrono version is currently on the 0.4.x branch, but there
are preparations to release a 0.5.x version. Explicitly specify a 0.4.x
version in our dependencies since there will be backwards-incompatible
API breakages in 0.5.x.
<https://github.com/chronotope/chrono/issues/970>
The exact version chosen (chrono 0.4.19) matches the version we have
pinned in Cargo.lock currently and will match any newer 0.4.x releases,
so there should be no functional change.
BUG=None
TEST=cargo build
Change-Id: Ifa24a547e435ab4987be9358343e6b25c1385c66
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4774870
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
This only has a sensible value when --bios is used; otherwise, we will
still end up with the previous value (0 meaning 64K BIOS ROM).
BUG=None
TEST=dmidecode
Change-Id: Ieef05d739bb6e9236cb90feb9bcaedfa23f67c3b
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4762784
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Zihan Chen <zihanchen@google.com>
Allows adding an optional serial number to the SMBIOS table.
BUG=b:249382713
TEST=crosvm run --smbios serial-number=abcdef ...
Change-Id: I00a00defb6904dbfa8ae38910b887e0a464787e3
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4761847
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Zihan Chen <zihanchen@google.com>
Reviewed-by: Mike Gerow <gerow@google.com>
Move oem_strings into a struct to allow for clearly-named parameters.
This allows overriding the default SMBIOS strings for BIOS and product
information.
BUG=b:282921262
BUG=b:249382713
TEST=cargo test -p x86_64
Change-Id: I5bf40f3c3ee1b675fdcaf427c15e5b0c74549379
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4761846
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Mike Gerow <gerow@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Zihan Chen <zihanchen@google.com>
Previously, dmidecode would complain that the table was one byte too
short. The final table only has a single 00h byte following it, but the
SMBIOS specification requires a double-null terminator (0000h) after
each structure. The other structures already meet this requirement
because they contain strings, which end in 00h; a single extra 00h
terminator byte is required in this case. On the other hand, the
END_OF_TABLE structure does not have any strings, so it needs to add two
00h bytes as a terminator.
Additionally, the end-of-table struct was represented with the
SmbiosSysInfo struct, which is the wrong size; the spec says the length
should be 4 (only including the type, length, and handle fields). Define
a new type to represent the end-of-table structure so the size is
correct.
Old dmidecode output:
> Handle 0x0003, DMI type 127, 27 bytes
> <TRUNCATED>
> Wrong DMI structures length: 104 bytes announced, structures occupy 105 bytes.
New dmidecode output:
> Handle 0x0003, DMI type 127, 4 bytes
> End Of Table
BUG=None
TEST=dmidecode in guest
Change-Id: Ic12487028d3fb4cf70918071744350272b6ccebe
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4761845
Reviewed-by: Mike Gerow <gerow@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Zihan Chen <zihanchen@google.com>
In order to replicate the ACPI notification from the host to the guest
pass-through devices:
1) allocate GPE and eventfd per pci-vfio device
2) generate proper aml code for ACPI GPE handler. The example of generated aml:
Scope (_GPE)
{
Method (_E00, 0, NotSerialized) // _Exx: Edge-Triggered GPE, xx=0x00-0xFF
{
Local0 = \_SB.PC00.PE08.NOTY
Notify (\_SB.PC00.PE08, Local0)
}
}
The eventfd is registered by host kernel via VFIO_DEVICE_SET_IRQS
ioctl. Crosvm upon receiving early provided, per pci-vfio eventfd,
stores the notification value and triggers GPE associated to pci-vfio
device.
Guest kernel upon handling GPE (thanks to generated aml [ad 2)],
triggers Notify on required pass-through device and therefore replicates
the ACPI Notification on the guest side [Accessing \_SB.PC00.PE08.NOTY
pointed by VCFG opregion result with trap to crosvm, which returns
previously stored notify value].
Kernel counterpart: CL:4538472
BUG=b:244205651
TEST=Observe replication of ACPI notification in the guest kernel
Change-Id: Iaf66097acd84f3066f6ff70d382f83ecaeea9a00
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4538483
Commit-Queue: Grzegorz Jaszczyk <jaszczyk@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
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>
Based on https://docs.kernel.org/arch/x86/boot.html#id1, this patch
adds a null GDT entry to match the Linux 64-bit Boot Protocol. With
this patch, CS is 0x10, DS, ES, and SS are 0x18.
Booted a bzImage and an ELF kernel, no issues observed.
TEST=cargo test -p x86_64
BUG=None
Change-Id: I234e9c43598fd5edb9d4e1b0fed1ba67f06a1845
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4680287
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Changyuan Lyu <changyuanl@google.com>
Always use the standard memory layout now that we are removing support
for the "direct" feature.
BUG=b:279218487
TEST=tools/dev_container tools/presubmit
Change-Id: Ic5b7a31d7bbc7715494c3c62126662023b50eb0b
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4550407
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Junichi Uekawa <uekawa@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>
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>
