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>
The new load_arm64_kernel() function loads and validates the Linux arm64
image format. This allows detecting whether the magic number and other
fields are valid, similar to the existing ELF loader.
BUG=b:254601048
TEST=Boot Crostini on arm
Change-Id: I62dc4670c2a216aa9a062f6d57ff945162e26037
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3976062
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
This will allow them to be used in a non-ELF kernel loader without being
misleading.
BUG=b:254601048
TEST=cargo test -p kernel_loader
Change-Id: I47e632e16b242813ffebcab88285b284cafcb6c2
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3995582
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
The code from configure_vcpu_early() is split into two parts:
1. vcpu_features() returns the `VcpuFeature`s required for vcpu.init()
2. vcpu_init() returns the general register state
This makes use of the new generic vcpu_init code path and moves the
general purpose register initialization into configure_vcpu() rather
than the ARM-specific confgiure_vcpu_early() to be consistent with other
architectures. Only the vcpu.init() call needs to happen before irqchip
is finalized on ARM, not other register setup.
BUG=b:237095693
TEST=tools/presubmit --all
TEST=Boot Crostini on trogdor
Change-Id: Ib3eab946ba9f1e407f339c2119d36d280655066f
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3786979
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Since the virtio allocates all available IRQ lines for VGIC,
system_allocator::allocate_irq() returns 32 for Goldfish battery,
but that is not handled by the VGIC. In the result, the interrupts
from Goldfish Battery device are dropped in the host kernel. Thus
even if the crosvm detects the AC unplug, it is not notified to
the guest.
To fix this issue, assign a static IRQ number (#3) to Goldfish
battery device as same as other devices, so that it can deriver the
interrupts correctly to the guest side via VGIC.
BUG=b:252582345
TEST=Boot the ARCVM and run 'dumpsys battery' and unplug/re-plug
AC connector several times, and confirm the AC status is updated.
Change-Id: Icdf3713cdf615d0039dd4e7719b80cad32333094
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3971137
Reviewed-by: Masami Hiramatsu <mhiramat@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Auto-Submit: Masami Hiramatsu <mhiramat@google.com>
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>
Introduce a set of helper methods that expose individual characteristics
that particular subsets of the ProtectionType variants share. These will
simplify various match statements into conditionals by encapsulating the
deduction of those characteristics, making the calling code more concise
and robust.
BUG=b:243646855
TEST=build
Change-Id: I65ff3e61c448d90704551b79c21c64d1b4c11dc4
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3944852
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
The pVM firmware memory region is allocated before
AARCH64_PHYS_MEM_START, but several parts of the code were assuming that
all memory was contiguous and after that.
BUG=b:244553205
TEST=Patched into AOSP and ran some VMs.
Change-Id: I8caefc9cae79c98ea62ee02a506b1b485d3f09a6
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3921604
Reviewed-by: Pierre-Clément Tosi <ptosi@google.com>
Commit-Queue: Andrew Walbran <qwandor@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Jiyong Park <jiyong@google.com>
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>
