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>
Devicetree bindings for restricted-dma-pool say that *either* "size" or
"reg" property should be used (but do not allow for both).
Each child node may either use a 'reg' property ... or a 'size'
property ...
Presently, "size" property is added even when fixed swiotlb region is
used. Apply the "size" property only when using dynamically allocated
swiotlb.
BUG=b:244630071
Fixes: 653f62a4a3 ("aarch64: static swiotlb allocation")
Change-Id: I1c88c9be043133e698e1da9072e5353ad7419e27
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4680283
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Frederick Mayle <fmayle@google.com>
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>
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>
Add devicetree node for a kvm-cpufreq device for arm64. If the guest
kernel has kvm-cpufreq driver and the host supports required hypercalls,
the kvm-cpufreq driver will start working.
This depends on out-of-tree kernel driver (crrev/c/4037181), so this
will be reverted when that driver is upstreamed correctly.
BUG=b:249685960
TEST=Boot ARCVM and confirm there are policies under
/sys/devices/system/cpu/cpufreq
UPSTREAM-TASK=b:256983979
Change-Id: I2f86e10a984b0adbbd93f34f39ee7e7b13571a6d
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4453483
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Auto-Submit: Masami Hiramatsu <mhiramat@google.com>
Commit-Queue: Masami Hiramatsu <mhiramat@google.com>
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>
MSRs are specific to x86/x86-64; add the appropriate cfg checks and
remove the MsrHandlers stubs from aarch64 and riscv64.
Change-Id: I94f0b5b4b9f75fecdc8e03c569f89a70b7f9f647
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4482135
Reviewed-by: Zihan Chen <zihanchen@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
BUG=b:244553205
TEST=Patched into AOSP and ran some VMs.
Change-Id: I95710fdb264a3bd1e8e69ed6dfad77bbc05b3043
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4440589
Reviewed-by: Jiyong Park <jiyong@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Pierre-Clément Tosi <ptosi@google.com>
Commit-Queue: Andrew Walbran <qwandor@google.com>
Gunyah initializes at VM level, not the vCPU level as KVM. Add
VM-generic initialization which happens after build_vm, but before the
VM starts to run.
BUG=b:232360323
Change-Id: Iea38cf63eca9b525e613450fd7bca2d422923063
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4400669
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Some hypervisors (presently: Gunyah) will configure boot-time registers
for vCPUs and not allow userspace VMM to set the boot configuration.
If this capability is declared, then crosvm will not try to initialize
vcpu registers upon VM bootup.
BUG=b:232360323
Change-Id: If2f05c832170f75eabfd7f0c63975465ba75aadf
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4379525
Commit-Queue: Frederick Mayle <fmayle@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Gunyah hypervisor requires some VM configuration to be described on the
devicetree. Add a trait to VmAArch64 to allow a hypervisor
implementation to provide the needed info.
BUG=b:253416076
Change-Id: I07091518b856add0c1644bf6a857460da7ff2b3b
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4379521
Reviewed-by: 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>
Today, it supports only loading ELF64 images. This change
allows to accept both ELF32 and ELF64 images.
BUG=b:261538125
TEST=cargo test -p kernel_loader -p aarch64
Change-Id: I54d125226abdfa21047f5590006e69e83a1b3fc5
Signed-off-by: Sahitya Tummala <quic_stummala@quicinc.com>
(cherry picked from commit 1abc72e6fea6d00d9e025251e354aa862f9e12e9)
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4346948
Reviewed-by: Dennis Kempin <denniskempin@google.com>
This is done similar to x86 platform to check if a kernel image have
ELF signature first and if it doesn't, then it is passed to the Image
loader as a fallback.
BUG=b:232360323
(cherry picked from commit f319faf8a070e5e5a7744ad0f64206d3a2704811)
Change-Id: I4604c7fc527c0fdf49971233ddba08fee5be4a8f
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4346945
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Remove KVM-specific code from the generic aarch64 module by providing a
generic enum for hypervisor-specific vCpus to use instead:
VCpuRegAArch64.
(cherry picked from commit cfd5acd14f924fe17f09c007fb20bf2abc632a79)
Change-Id: I486ea24993493c314ed6dacd5cedeeb135225135
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4346944
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>
In case the final devicetree blob is too large to fit in the memory
reserved for it, it could be useful to inspect the generated FDT. Move
the code that dumps the FDT to a file before the length check so it will
be written out even if the size is too large.
BUG=None
TEST=crosvm run --dump-device-tree-blob /tmp/fdt # on aarch64
Change-Id: I1344d08cee5cb7eb0fd369314f2b765e37f18215
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4277621
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Shin Kawamura <kawasin@google.com>
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>
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>
We will enable clippy checks on those platforms in CI soon.
BUG=b:268356784
TEST=tools/clippy --platform=aarch64/armhf
Change-Id: Icfefdbce7498731d78448b00c7c21a0f86639dff
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4233580
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
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>
Replace the OS-specific /dev/urandom with the cross-platform rand crate.
BUG=b:265031416
TEST=Boot aarch64 Linux kernel on lazor
Change-Id: I6eb3ab4c5b45bc8296ade92b5b5e30da78d039d2
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3855345
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Drop a few unused kvm dependencies and only require minijail on unix
platforms.
The aarch64 platform won't be functional on Windows yet, but it's at
least possible to drop it from the WIN64_DISABLED_CRATES list.
BUG=None
TEST=tools/dev_container tools/run_tests --platform=mingw64
TEST=tools/dev_container tools/run_tests --platform=aarch64
Change-Id: If48b935afe1295820b6d78cfde3e8634a3e397db
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4167144
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Rename the ProtectVm variant to better describe what it actually covers
i.e. a request to the hypervisor to load the protected fw (note: the VM
is actually protected in KvmVm::new()) and clarify its error message.
To better distinguish between the two cases and as they differ in
underlying error types, make it clear that PvmFwLoadFailure was only
used for "custom" pvmfw images, loaded by crosvm.
TEST=tools/dev_container cargo build --target aarch64-unknown-linux-gnu
Change-Id: I80caa1e52ea7322c5394f246ef020d17bdef4476
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4136213
Auto-Submit: Pierre-Clément Tosi <ptosi@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: 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>
Today, it supports only loading ELF64 images. This change
allows to accept both ELF32 and ELF64 images.
BUG=b:261538125
TEST=cargo test -p kernel_loader -p aarch64
Change-Id: Ic9e6eadfc308c317e9bed7ef657e1b5777da897f
Signed-off-by: Sahitya Tummala <quic_stummala@quicinc.com>
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4089657
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Steven Moreland <smoreland@google.com>
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>
When running a VM with a flavor of the --protected-vm flag, crosvm loads
the bios or kernel image but the VM first runs the protected firmware,
which is expected to verify those preloaded images before executing
them.
Previously, a custom ABI was used to allow crosvm to pass the location
and size of the image to the firwmare through CPU registers. Instead,
pass those parameters through the device tree to comply with the Linux
ABI and be more architecture-agnostic.
Use the /config node (ignored by Linux, used by U-Boot in a similar way)
to pass the newly-introduced 'kernel-address' and 'kernel-size'
properties, which follow the naming and size of the existing
'kernel-offset' [1].
[1]: https://u-boot.readthedocs.io/en/latest/develop/config_binding.html
BUG=b:253616035
TEST=Dump DT from guest
Change-Id: If9e3470ed03372adcddb268444daa159ed9fa5a2
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4064759
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Auto-Submit: Pierre-Clément Tosi <ptosi@google.com>
Commit-Queue: Pierre-Clément Tosi <ptosi@google.com>
This interprets the p_paddr field of ELF program headers as an offset
into physical RAM on aarch64 systems, which is a change in behavior. We
pass an offset of 0 on x86-64, so it makes no difference there.
BUG=b:254601048
BUG=b:255697205
TEST=cargo test -p kernel_loader
Change-Id: I9ebaa285c4cde1f70cb7752e91ff4520e06dc82f
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4035738
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
There is no reason to leave an 8 MB gap at the beginning of guest
memory; shift the kernel load address down to the very beginning of
RAM. This accomodates alternate ELF kernels that want to be loaded at
address 0 as well.
BUG=b:254601048
TEST=boot crostini on arm
Change-Id: Iaa58efc5b20046732ef0f75b3c779134a3ee454b
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4015002
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
