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>
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>
Currently, we ignore clippy::needless_return, with many violations in
the code base. This CL fixes trivial, safe-to-fix violations of
needless_return. These were found by removing the needless_return
suppression in .cargo/config.toml and then fixing needless returns.
These are not all needless returns in the code base; it is only the
trivial fixes. This CL is a part of a chain of CLs to fix the
needless_returns in the code base.
BUG=chromium:908640, b:157245930
TEST=cargo clippy + cargo build
Change-Id: I6f8f3a0bed25d774fba7ae4b6e4c021af439ec22
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4014832
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Clarissa Garvey <clarissagarvey@chromium.org>
These tests require access to kvm and are not suitable for a unit test.
The tests are unmodified and only some visibility changes were made
to allow them to become integration tests.
BUG=b:244623785
TEST=presubmit
Change-Id: I916360f14dba204caca846957bebccf77d451631
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4004344
Auto-Submit: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
The crates do the same thing, but static_assertions is
proven and stable, with no added dependencies.
Note: While this won't require changes to chromeos ebuild files
it will require the removal of dev-rust/assertions when crosvm-base
is upreved.
BUG=b:255989923
TEST=presbumit
Change-Id: I1420447ebdaa1a3649b30e6a6ec57f8dee858b98
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3988328
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
This will let the hypervisor crate use types and functions from the new
cros_fdt crate (it could not depend on arch, since that would cause a
circular dependency).
No functional change, just code movement.
BUG=b:253416076
TEST=cargo build
TEST=cargo build --target=aarch64-unknown-linux-gnu
Change-Id: I62d906941867c45f1b77ff1db6923d915ce2123e
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3965088
Reviewed-by: Steven Moreland <smoreland@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
The current crosvm implementation is using
`GuestMemory::checked_offset()` for the following two cases:
(1) To get a valid `GuestAddress` representing `addr + offset`.
(2) Guarantee that the memory range `[addr, addr+offset]` is valid.
However, using `checked_offset()` for the case (2) is wrong because the
method only checks if the end address `addr+offset` is valid and doesn't
check if an invalid region exists between `addr` and `addr+offset`.
So, this CL adds `GuestMemory::is_valid_range()` to replace the (2)
cases.
BUG=b:251753217
TEST=cargo test in vm_memory
TEST=start a vm with virtio devices
Change-Id: I21bce5d1c60acdff79284cdad963849a6e19e19c
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3945520
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: David Stevens <stevensd@chromium.org>
Reviewed-by: Noah Gold <nkgold@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Add the infrastructre for GDB 'p'/'P' packets, used by the client to get
or set individual registers.
Implement a back-end using KVM_{G,S}ET_ONE_REG on AArch64, enabling the
client to access the architecture's numerous system registers.
Add stubs for x86 to please the compiler; leave them unimplemented as,
although the ioctl is available, the architecture doesn't seem to make
use of it.
BUG=b:222222882
BUG=b:240711627
BUG=chromium:1141812
TEST=tools/dev_container ./tools/run_tests
Change-Id: I01968275e88e9d0098de40b3f78e2cd3a61b75da
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3785468
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
This reverts commit fa1e6e3249.
Reason for revert: This turns out to have been a bug in the kernel that can be addressed with the following patch:
```
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index 2d7ea5480ec3..71b412f820c7 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -328,6 +328,7 @@ static void early_init_intel(struct cpuinfo_x86 *c)
pr_info("Disabled fast string operations\n");
setup_clear_cpu_cap(X86_FEATURE_REP_GOOD);
setup_clear_cpu_cap(X86_FEATURE_ERMS);
+ setup_clear_cpu_cap(X86_FEATURE_FSRM);
}
}
```
Original change's description:
> x86: cpuid: clear FSRM bit
>
> This seems to cause an unexpected fault under Bruschetta, and possibly
> any other software using Ice Lake's Fast Short REP MOVs.
>
> This is a port of a patch from AOSP[1].
>
> [1]: https://android-review.googlesource.com/c/platform/external/crosvm/+/2138413
>
> BUG=b:228795137
> TEST=deployed to brya board, bruschetta bootup no longer hangs after
> entering smpboot
>
> Change-Id: Ifb4e8af104ee8e2945598ea4c06001cbd98c40e9
> Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3913990
> Auto-Submit: Mike Gerow <gerow@google.com>
> Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
> Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Bug: b:228795137
Change-Id: I7bd8be1b33315dddb5b73df62303bd967ac0573e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3916337
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Auto-Submit: Mike Gerow <gerow@google.com>
This MSR seems to be the responsibility of the hypervisor to set up even
when booting with BIOS/firmware in the guest. When it is missing, the
configuration of IA32_MISC_ENABLE will be inconsistent with CPUID bits
like ERMS and FSRM, which report fast REP MOVSB behavior as well.
Specificially, this avoids a problem with newer Linux kernels when
booted in crosvm with a BIOS where the ERMS feature is masked out due to
the IA32_MISC_ENABLE bit being unset but the FSRM feature is not masked
out, leading to a normally impossible combination of CPUID features that
the memmove code did not expect.
BUG=b:228795137
TEST=Boot Linux with OVMF on brya
Change-Id: I9e9e8301d8cb3d1f0f0d0c7d2137ff3286f35c1d
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3919374
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Mike Gerow <gerow@google.com>
This seems to cause an unexpected fault under Bruschetta, and possibly
any other software using Ice Lake's Fast Short REP MOVs.
This is a port of a patch from AOSP[1].
[1]: https://android-review.googlesource.com/c/platform/external/crosvm/+/2138413
BUG=b:228795137
TEST=deployed to brya board, bruschetta bootup no longer hangs after
entering smpboot
Change-Id: Ifb4e8af104ee8e2945598ea4c06001cbd98c40e9
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3913990
Auto-Submit: Mike Gerow <gerow@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
While we are tweaking all of the copyright headers, let's take the
opportunity to ensure there is always a blank line after the copyright
header for consistency. (Almost all files already follow this style.)
This includes a slightly ugly regex to allow the end of a C-style
comment block after the end of the copyright:
/*
* Example comment block
*/ <-- this line
Change-Id: Idfd0855861e5ecb3d33afae942fdba908af0dcff
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3892521
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
This search/replace updates all copyright notices to drop the
"All rights reserved", Use "ChromiumOS" instead of "Chromium OS"
and drops the trailing dots.
This fulfills the request from legal and unifies our notices.
./tools/health-check has been updated to only accept this style.
BUG=b:246579983
TEST=./tools/health-check
Change-Id: I87a80701dc651f1baf4820e5cc42469d7c5f5bf7
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3894243
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
We are going to need to start passing a new arch-dependent configuration
parameter to KvmVm::new in addition to protection_type. Since we can't
[cfg] a function argument, and to avoid churning the tests the next time
we need another argument, let's create a hypervisor::Config struct and
start passing protection_type that way.
Bug: b:234779841
Change-Id: I42ce9438b064658ebb9732e78ee5c82dac2636b6
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3892140
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Peter Collingbourne <pcc@chromium.org>
Type 11 SMBIOS OEM strings entries are commonly used to pass arbitrary
information into a VM. For example, systemd's credentials[1] system
looks for specially formatted values here.
The main goal here is to allow parameterization of a VM when we're
booting with OVMF, in which case providing parameters via the kernel
cmdline is less useful.
QEMU suports something similar, but this is a significantly simplified
approach, allowing only OEM strings instead of a wider range of DMI
table entries QEMU allows customizing.
[1]: https://systemd.io/CREDENTIALS/
BUG=b:244366989
TEST=cargo test; passed oem strings into vm and confirmed they are in
dmi tables
Change-Id: I5e106983e624c8a244b8074d6944bc0c9acfd748
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3868327
Auto-Submit: Mike Gerow <gerow@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Mike Gerow <gerow@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
The derived method matches what we provide, so just use the derived
method instead of unnecessarily creating our own.
BUG=b:244366989
TEST=build, confirm smbios entries still work
Change-Id: Ia5668c4bcf496cfadcc8f7ca153661df6a1d180d
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3881045
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Auto-Submit: Mike Gerow <gerow@google.com>
Tested-by: Mike Gerow <gerow@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
For vfio-pci device, guest couldn't call this device's acpi method like
_DSM/_DSD/_PS0..., in order to let guest run it, crosvm will provide
virtual method to guest, this virtual method pass guest method call into
host and pass host return value into guest.
This commit adds a function into pci device trait, which returns the
aml code to construct virtual acpi method. Two pages mmio are used to
pass acpi parameters and return value, when guest access the first page,
vm exit happens and it is trapped into crosvm, when guest access the
second page, no vm exit happens.
Co-authored-by: Victor Ding <victording@google.com>
BUG=b:194390621
TEST=tools/presubmit
Change-Id: I71797394de61437d4d105e65488d36511c71cbd7
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3813137
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Victor Ding <victording@chromium.org>
Commit-Queue: Victor Ding <victording@chromium.org>
Rename all local variables across the codebase to be consistent with the
recently renamed cfg.protection_type (from cfg.protected_vm). This
commit is intended to make the renaming less cumbersome to review.
Note: no functional change intended.
BUG=b:243646855
TEST=build
Change-Id: I495b0854ce60cb1dc041ef43480fe11b379883c2
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3867616
Tested-by: Pierre-Clément Tosi <ptosi@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Pierre-Clément Tosi <ptosi@google.com>
Improve clarity and consistency between the variable and its type, given
that it represents the protected/unprotected state AND whether some
firmware needs to be used. In particular, it isn't the protected VM
itself.
Similarly, rename components.protected_vm for the same reason.
OTOH, keep cmd.protected_vm for --protected-vm as it is dedicated to
making the VM protected and follows the name of the CLI flag.
Note: no functional change intended.
BUG=b:243646855
TEST=build
Change-Id: Id91d1c83e9efa79562022dacf37f4c89e451f2b5
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3867615
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Pierre-Clément Tosi <ptosi@google.com>
Bump the versions of these crates as we're about to require support for
unavailable register values and AArch64. Do it in a separate commit to
ease future bisects.
BUG=b:222222882
BUG=chromium:1141812
TEST=tools/dev_container ./tools/run_tests
Change-Id: I0bfa3559d172faf2df6bcffdc77714830f442051
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3785466
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Auto-Submit: Pierre-Clément Tosi <ptosi@google.com>
Tested-by: Pierre-Clément Tosi <ptosi@google.com>
Commit-Queue: Pierre-Clément Tosi <ptosi@google.com>
Reviewed-by: Takaya Saeki <takayas@chromium.org>
Make GdbStub query the number of available hardware breakpoints from the
VM as some architectures (e.g. AArch64) might permit a flexible number.
BUG=b:222222882
BUG=chromium:1141812
TEST=tools/dev_container ./tools/run_tests
Change-Id: I9220f642fc01939305bd17461eaf50c424d998bc
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3785465
Auto-Submit: Pierre-Clément Tosi <ptosi@google.com>
Commit-Queue: Pierre-Clément Tosi <ptosi@google.com>
Tested-by: Pierre-Clément Tosi <ptosi@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Takaya Saeki <takayas@chromium.org>
Remove target_arch-specific #[cfg]s where the underlying code is
architecture-agnostic.
Introduce a GdbOps trait for architectures to implement.
Make use of the generic gdbstub::arch::Arch trait where relevant.
Import base::Tube unconditionally in arch/src/sys/unix.rs.
Expand crate::gdb::* in vm_control/src/lib.rs for clarity.
Keep target_arch checks in x86-specific code to exclude 32-bit builds as
those don't seem to provide GDB support.
BUG=b:222222882
BUG=chromium:1141812
TEST=tools/dev_container ./tools/run_tests
Change-Id: I3f5ceeeb9031bee222ecd388dddb815e256748e8
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3785464
Tested-by: Pierre-Clément Tosi <ptosi@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Auto-Submit: Pierre-Clément Tosi <ptosi@google.com>
Commit-Queue: Pierre-Clément Tosi <ptosi@google.com>
Virtio MMIO device needs only one MMIO region and one edge-triggered
IRQ. Both based MMIO address and IRQ number are allocated dynamically.
BUG=b:189182339
TEST=boot manatee and verify that Virtio PCI devices work properly
Change-Id: Icdd6213068ef05c5a71e23728e2a4e1d69ac454b
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3855009
Commit-Queue: Tomasz Nowicki <tnowicki@google.com>
Tested-by: Tomasz Nowicki <tnowicki@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Lookup Vitio MMIO devices and allocate resources:
- hardcoded 0x200 size single MMIO region to configure vrings
- just one shared and edge-triggered IRQ to notify guest
- per-queue ioevents to poke host
Then plug device into main bus.
BUG=b:189182339
TEST=boot manatee and verify that Virtio PCI devices work properly
Change-Id: Ic255b2c9cdf1cb43b8663d39970daf54e55c6eed
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3855008
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Tomasz Nowicki <tnowicki@google.com>
Commit-Queue: Tomasz Nowicki <tnowicki@google.com>
If a vfio-platform device has no mmio regions, it is unexpectedly
destroyed at startup (in particular, its vfio device fd is unexpectedly
closed, so its interrupt forwarding stops working, etc) since in
generate_platform_bus() arced_dev is not added to mmio_bus so there are
no more references to the device. To fix this issue, preserve references
to platform devices also in platform_devices field of RunnableLinuxVm.
BUG=b:197169350
TEST=Use vfio-platform for passthrough of a device with interrupts but
without mmio regions, e.g. touchpad on Brya, and check if it works in
the VM (i.e. its interrupts are successfully delivered).
Change-Id: I4042c5508ef6b69649c7d20962edf61b735abc03
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3820043
Commit-Queue: Dmytro Maluka <dmaluka@google.com>
Tested-by: Dmytro Maluka <dmy@semihalf.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
The generated ACPI devices are given deterministic names from PCI
addresses and topology. ACPI requires a device defined before any
reference or usage. For example, PCI switch must occur before its
downstream devices, and "Device" must occur before any "Scope"
extending it. By providing skeleton device definitions in DSDT, it
dramatically eases the composition of SSDT, especially when a device
is referenced in multiple SSDTs or "Scopes".
BUG=b:194390621
TEST=Dump DSDT and verify
Change-Id: Id9f74130b2c1f250374a3103db952ee10fa1b5ee
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3844817
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Auto-Submit: Victor Ding <victording@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Include the error code and path to the file that failed to open. Then we
can remove the redundant file existence check in validate_config.
BUG=None
TEST=crosvm run --dmi /does/not/exist vm_kernel
Change-Id: Id857284c521aaa958a8b7967d7c2de81adcb74a5
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3806075
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
There could be at most 256 PCI buses. Using "PCxx" naming convention
allows easily naming all possible PCI buses.
BUG=b:194390621
TEST=Dump DSDT and verify
Change-Id: I53c054555460e3a37b57d2ef6c71972949dd1bd3
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3844816
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Auto-Submit: Victor Ding <victording@chromium.org>
Tested-by: Victor Ding <victording@chromium.org>
Minor code refactor to improve readability.
BUG=b:194390621
TEST=Dump DSDT with and without this patch; then ensure they are
identical
Change-Id: Iccc62803788c3e44ce5f0cb8322831c015a95f85
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3844815
Auto-Submit: Victor Ding <victording@chromium.org>
Tested-by: Victor Ding <victording@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Victor Ding <victording@chromium.org>
The auto-generated _OSC in DSDT is incorrect, fixing it.
BUG=None
TEST=Dump DSDT table and verify the generated _OSC
Change-Id: Ib6c5c355a7b6ebb6c891b8f3c685e59d4117abad
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3831821
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Auto-Submit: Victor Ding <victording@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Extend pci device's vcfg mmio size frome 4k to 8k, the first page is
trapped by crosvm, the second page is share memory between guest and
crosvm, so that guest could read/write it directly without vm exit.
BUG=b:194391459
TEST=check vcfg mmio size for each pci device
Change-Id: If5ac75b4dc8a829cabce4370e7592f23600e4ef8
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3813136
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Victor Ding <victording@chromium.org>
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Pcie vcfg use similiar pcie ECAM to distribute vcfg mmio into
each pci device, in order to make each pci device has such pcie
vcfg mmio, its size should be same as pcie ECAM.
BUG=b:194391459
TEST=check each device's pcie vcfg mmio in guest
Change-Id: I1ca13384514f323b1e49decd3de198bdfa3ac347
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3813135
Reviewed-by: Victor Ding <victording@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
pcie_cfg_mmio_range has been gotten at the beginning of build_vm,
and its value won't be changed. So later it could be used directly
instead of read_pcie_cfg_mmio() again.
BUG=None
TEST=tools/presubmit
Change-Id: If52843634692bbd9cec7b3679856a3959b41f397
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3813134
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Victor Ding <victording@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
This patch adds support for hotplug pcie switch. The user send
HotplugCommand of the new added device with the same order they
appear in device tree, and in handle_hotplug_command we add device
accordingly. During hotplug out, firstly vfio endpoint device will
send hot unplug command, we remove these endpoint device immediate-
ly, and then remove any bridge that is hotplugged into the system
but with zero child device connected to it. When all child bridges
got cleared up and pcie root port have no child devices, we send
plug out interrupt to guest kernel and probe hotplug out handling
in guest.
BUG=b:199986018
TEST=hotplug in and out pcie switch repeatedly
Change-Id: Ic3ab86d14efba4d05e204936e08bc6a582723484
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3769817
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Just like with GPE, wire up ACPI fixed event forwarding eventfd and
crosvm's ACPI fixed event emulation.
This patch allows to provide ACPIPMResource with the list of fixed
events which should work as direct physical (passthrough) events rather
than purely emulated ones.
BUG=b:228445196
TEST=compiles
Change-Id: I6f50f24fc0b9c187e48140dbafb7926ece4b9961
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3791194
Commit-Queue: Dmytro Maluka <dmaluka@google.com>
Tested-by: Dmytro Maluka <dmy@semihalf.com>
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Similarly to GPE passthrough, in order to allow handling physical
fixed events in the guest, implement PM1 status & enable register
bits read/write passthrough to/from physical registers for selected
fixed events (while for the rest of fixed events PM1 registers
remain purely emulated).
Like with GPE, we assume that those fixed events are enabled/disabled
exclusively by the guest, never by the host.
BUG=b:228445196
TEST=compiles
Change-Id: I7855a05f4efd00954d24cc1c93e245ba260421c5
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3791192
Commit-Queue: Dmytro Maluka <dmaluka@google.com>
Tested-by: Dmytro Maluka <dmy@semihalf.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
A few new grouped imports have made it in since the tree-wide
reformatting.
BUG=None
TEST=tools/presubmit
Change-Id: I93af3c741f57c1da73d4c9e8a28be424c1ea45fe
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3818244
Auto-Submit: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Hotplug command is facing dead lock issue when it tries to acquire
the lock for pci root in the vm control thread. Dead lock could
happen when the vm control thread(Thread A namely) is handling the
hotplug command and it tries to get the lock for pci root. However,
the lock is already hold by another device in thread B, which is
actively sending an vm control to be handled by thread A and
waiting for response. However, thread A is blocked on acquiring the
lock, so dead lock happens. In order to resolve this issue, we add
a new pci root worker thread and push all work that locks pci root
to this thread.
BUG=b:199986018
TEST=tools/presubmit
Change-Id: I11552a1c9c626035d0ca01ce2835fd8b6c067a67
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3765366
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
HWP CPUID bits are decoupled from ITMT feature and the related MSRs are
passthru to ChromeOS by default, thus we no longer need to setup HWP
MSRs at the time of enabling ITMT or PnP.
BUG=b:199380745
TEST=boot Redrix manatee and verified that all related features work
Change-Id: Ia600863f0846ed14e669b0bd3963ec175d148554
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3771066
Commit-Queue: Dmitry Torokhov <dtor@chromium.org>
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Tested-by: Dmitry Torokhov <dtor@chromium.org>
Expose HWP (HW P-State) feature to the guest if enable-hwp is present
and implement these dependencies:
- enable-hwp depends on host-cpu-topology option
- itmt depends on enable-hwp option
Group the CPU configuration entries to a new struct CpuConfigArch,
to simplify APIs in the vCPU configuration path.
BUG=b:199380745
TEST=boot Redrix manatee and verified that intel_pstate driver works
Change-Id: Icdd19190f6a7518492ff5fc54708af40288a1422
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3771065
Commit-Queue: Dmitry Torokhov <dtor@chromium.org>
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Tested-by: Dmitry Torokhov <dtor@chromium.org>
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
Add a function pointer to Cmos::new() to retrieve the time so we can
test against fixed times in the tests.
BUG=None
TEST=cargo test -p devices cmos
Change-Id: I0ed73b8742c0fe85fa13541b6fef1b534d81c088
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3795010
Reviewed-by: Noah Gold <nkgold@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
This requires the introduction of a BatteryConfig structure to parse,
which is probably a good idea anyway as it reserves some space to add
more battery-related options.
BUG=b:218223240
TEST=cargo test parse_battery
Change-Id: I82db7fe7ce2daeca004e734aaafa542583998561
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3784661
Tested-by: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
The code was unintentionally subtracting 1 (to get the inclusive end
address) twice, leaving off one extra byte. This doesn't make much
difference in practice since the high MMIO region is typically very
large (up to 64 terabytes).
The result can be observed in the guest's /proc/iomem, where the PCI
region should now end at 0x..ffff instead of 0x...fffe.
BUG=None
TEST=Boot x86-64 Linux kernel; cat /proc/iomem
Change-Id: I2df210ed40612cefce68926c616f455e416ed40c
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3790030
Reviewed-by: David Stevens <stevensd@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
- Remove trailing ::{self} on all use statements
- Remove any resulting single-level use statements (e.g. use libc;)
- Reformat with `tools/fmt --nightly`
BUG=b:239937122
TEST=tools/dev_container tools/presubmit --all
Change-Id: I8afd1b0458ca6d08d9b41a24583f7d4148597ccb
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3798973
Auto-Submit: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
crosvm is switching the import style to use one import per line.
While more verbose, this will greatly reduce the occurence of merge
conflicts going forward.
Note: This is using a nightly feature of rustfmt. So it's a one-off
re-format only. We are considering adding a nightly toolchain to
enable the feature permanently.
BUG=b:239937122
TEST=CQ
Change-Id: Id2dd4dbdc0adfc4f8f3dd1d09da1daafa2a39992
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3784345
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Loading 32-bit images is needed for kvm-unit-tests.
BUG=b:233317135
TEST=boots, new unit tests
Change-Id: I6ba63255e0e2993f3735ef81489f64dbd0bb6374
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3764465
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Auto-Submit: Steven Richman <srichman@google.com>
Tested-by: Steven Richman <srichman@google.com>
Commit-Queue: Steven Richman <srichman@google.com>
Do not use a reference when it's not safe to call minijail.fork() multiple
times.
BUG=b:238646369
TEST=build
Change-Id: I91def471ef64ef11ba32032ccc095d5282362d62
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3779079
Reviewed-by: Noah Gold <nkgold@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Junichi Uekawa <uekawa@chromium.org>
Tested-by: Junichi Uekawa <uekawa@chromium.org>
