These Vcpu functions are never called anywhere (some were previously
used but the uses have been removed; some were part of the initial
hypervisor API port and were never used):
- get_hyperv_cpuid()
- handle_hyperv_hypercall()
- handle_rdmsr()
- handle_wrmsr()
Additionally, these KVM-specific VM functions that are no longer called
can be removed (related to the handle_rdrmsr/handle_wrmsr functions):
- enable_userspace_msr()
- set_msr_filter()
Remove the dead code (including the corresponding VcpuExit codes where
relevant) to simplify the Vcpu API.
If these are ever re-added, they should be implemented on VcpuX86_64
rather than the generic Vcpu, as they are x86-specific features.
BUG=b:337131577
TEST=tools/dev_container tools/presubmit
Change-Id: I0187127170b30d7720212e26a84fd06773c824c4
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5499407
Reviewed-by: Idan Raiter <idanr@google.com>
Reviewed-by: Noah Gold <nkgold@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
This should never actually get returned by a hypervisor in practice; if
it does, treat it like any other unknown exit type and panic immediately
in the hypervisor-specific VM exit handling code. This will give us the
best chance of debugging such a (hypothetical) situation, since the VM
exit information (struct kvm_run or equivalent) will be available at the
time of the panic/crash report.
This VCPU exit type was never actually handled in the vcpu run loop, so
it would have caused a panic anyway, just later.
BUG=b:337131577
TEST=tools/dev_container tools/presubmit
Change-Id: I767c04e0d04898b0dbecf9a492753cd8d99ecae4
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5484145
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Idan Raiter <idanr@google.com>
Reviewed-by: Noah Gold <nkgold@google.com>
When a guest offlines CPUs, the pv clock structures of those CPUs are
marked as inactive, which causes the KVMCLOCK_CTRL ioctl to return
EINVAL. Ignore this to prevent spurious failures when the guest enters
S3.
BUG=b:301862490
TEST=Manual test with ArcS2Idle feature flag
Change-Id: I9eaaa7a2645151601e90b5966ccf4069dddda1c1
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5491342
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: David Stevens <stevensd@chromium.org>
The gdb support is implemented outside of the hypervisor crate now,
aside from two debug-specific VcpuAarch64 functions, which don't depend
on the gdbstub crate for their API. Drop the cfg checks and make these
APIs always available (the compiler will optimize them out if they are
not called anyway) and remove the unused gdbstub dependencies.
BUG=b:323354478
TEST=tools/dev_container tools/presubmit
Change-Id: Ieb313a1098239e9d764207c9cb6cc18c8a376795
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5500375
Reviewed-by: Frederick Mayle <fmayle@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Exit reasons that are specific to an architecture are moved into the
arch-specific implementation of KvmVcpu::handle_vm_exit_arch().
Exit reasons that are only used on architectures not currently supported
by crosvm are removed:
- s390 only: KVM_EXIT_S390_*
- power only: KVM_EXIT_PAPR_*, KVM_EXIT_DCR, KVM_EXIT_NMI, KVM_EXIT_OSI,
KVM_EXIT_WATCHDOG, KVM_EXIT_EPR
BUG=b:337131577
TEST=tools/dev_container tools/presubmit
TEST=start Crostini on x86-64 and aarch64
Change-Id: Id31a8b126feef5b49cfbb4537abe1fd9350c14f5
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5484144
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Takaya Saeki <takayas@chromium.org>
Initially, time was not being restored in the VM unless we restore the
offset. This was possibly due to a different bug, where we weren't
restoring all the MSRs.
5441c064e5
BUG=b:327278462
TEST=boot crosvm. snapshot. restore. check time of VM == time of snapshot.
Change-Id: I2d4b6d7beba6c40fd37635b5f108559f65c6dd9f
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5492298
Reviewed-by: Steven Moreland <smoreland@google.com>
Auto-Submit: Elie Kheirallah <khei@google.com>
Reviewed-by: Frederick Mayle <fmayle@google.com>
Commit-Queue: Elie Kheirallah <khei@google.com>
This moves the system register encoding infrastructure to the generic
aarch64 level (out of KVM), which will allow it to be used for snapshot
and restore code for all hypervisors.
Additionally, the two system registers that KVM API encodes incorrectly
are handled in the AArch64SystemReg to KvmVcpuRegister mapping function
(CNTV_CVAL_EL0 and CNTVCT_EL0).
Now that the hypervisor API exposes enough functionality to get and set
the basic architectural state for aarch64, we don't need to implement
the gdbstub-specific API inside each hypervisor; it can be moved into
the aarch64 architecture support module instead.
BUG=b:323354478
TEST=tools/dev_container tools/presubmit
Change-Id: I257d24060dec177f89e233cbdbf80e5df9641742
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5441434
Reviewed-by: Elie Kheirallah <khei@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Frederick Mayle <fmayle@google.com>
Reviewed-by: Pierre-Clément Tosi <ptosi@google.com>
Don't return an error from set_msr() if the msr is unsupported. This
restores the behavior before https://crrev.com/c/5436901.
Vcpu init sets MSR_IA32_MISC_ENABLE, which isn't available in the WHPX
API.
BUG=b:335596949
TEST=boot
Change-Id: I85d122e781dd04e6f6def135caef93a0d8c559ad
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5469381
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Allow getting and setting vector registers through a separate API, since
they are 128 bits wide, unlike other registers exposed via get_one_reg()
and set_one_reg().
BUG=b:323354478
TEST=tools/dev_container tools/presubmit
Change-Id: I6cf51472fed893f33a0ecebf124597a0227f6580
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5440819
Reviewed-by: Frederick Mayle <fmayle@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Replace the Vec<Register> with a simpler Map<u32, u64>.
This changes the snapshot JSON schema - the "msrs" field will now be a
JSON dictionary (object) with the MSR index as key rather than a list of
objects.
Change-Id: I71a26dec6bcdaae0b66d497818a65b8c143eea8b
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5436912
Reviewed-by: Frederick Mayle <fmayle@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
All existing x86-64 hypervisor implementations use the same TSC
manipulation functions that use the vcpu's get_/set_msr() functions.
Move these helper functions into the default implementation in the trait
instead of requiring each hypervisor to call them explicitly.
No functional change.
Change-Id: If8abe083ee39eab1f3083584896dba8425964d6f
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5436902
Reviewed-by: Frederick Mayle <fmayle@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
All of the callers of the previous VcpuX86_64 MSR get/set APIs either
want a single MSR or all known/supported MSRs. The previous get_msrs()
API was inconvenient for the single-MSR case, and it required a slightly
unusal calling convention where the caller needed to fill a Register
struct with an unused initial value that would be replaced by the actual
value.
This change replaces the get_msrs()/set_msrs() APIs with single-register
get_msr()/set_msr() functions, which have a much more natural API. The
new get_msr() function accepts an MSR index and returns its value, and
the new set_msr() function accepts an MSR index and value.
The only user of set_msrs() was the vcpu initialization code, which will
now call set_msr() for each individual MSR; since there are very few MSR
values to set normally (15), this makes very little difference in
startup time.
get_msrs() was not needed in the public API at all, and get_all_msrs()
still retrieves multiple MSRs in one shot where this makes sense.
BUG=None
TEST=tools/dev_container tools/presubmit
Change-Id: I8cbe692cd528b8f9e7cfea18a28d4d8c83dac794
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5436901
Reviewed-by: Frederick Mayle <fmayle@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
On AArch64, Linux expects the <reg> property to match the MPIDR:
> On ARM v8 64-bit systems <reg> is required and matches the MPIDR_EL1
> register affinity bits. If cpus node's #address-cells property is set
> to 1 the reg cell bits [23:0] must be set to bits [23:0] of MPIDR_EL1.
> All other bits in the reg cells must be set to 0.
so introduce the plumbing to let hypervisor backends describe the MPIDR
topology while generating the FDT. For now, use a default implementation
that matches the previous behavior for all realistic topologies (i.e.
when the VM has 16777215 or fewer vCPUs).
Keep generating the DT with #address-cells=1, even if it limits us to
bits MPIDR_EL1[23:0], as that is more than enough with the default
topology.
Bug: b/331362077
Test: tools/run_tests -p aarch64
Change-Id: I4850e582f197b53bdfce7fe6c40c2c9726c65c6b
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5401898
Commit-Queue: Pierre-Clément Tosi <ptosi@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Constructing a SafeDescriptor from file descriptor -1 will panic at
runtime when it becomes an OwnedFd wrapper. Rework the test code to
generate an Event with an invalid, but not that invalid, file
descriptor.
BUG=b:242953353
TEST=tools/dev_container tools/presubmit
Change-Id: I0c4865fc90f1c83ec9fb1a1dc1fa0600ce14f479
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5354689
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
The hypervisor::haxm module is only available for cfg(windows), so make
the cfg wrapping the tests use the same condition as the haxm module.
In theory, HAXM is available on Linux, but we don't support that; this
change makes the cfg checks consistent so that building and testing with
--features=haxm on Linux can succeed (without actually enabling HAXM).
TEST=cargo nextest run --workspace --features=haxm # on Linux
Change-Id: I6642acbe145ab8a44600e151443e05d349e05681
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5354026
Reviewed-by: Noah Gold <nkgold@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Add a top level noncoherent-dma feature flag as well as its
counterparts in devices and hypervisor modules.
This flag enables the MemCacheType::CacheNonCoherent handling,
ensuring that behavior introduced in the previous commit can be
selectively enabled.
BUG=b:316337317
TEST=emerge-rex chromeos-base/crosvm
TEST=USE=crosvm-noncoherent-dma emerge-rex chromeos-base/crosvm
Change-Id: I13f50547b21ce804c5fa4b8f6328931f558b717e
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5237126
Reviewed-by: Frederick Mayle <fmayle@google.com>
Reviewed-by: Zhenyu Z Wang <zhenyuw@linux.intel.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Stanisław Kardach <skardach@google.com>
On Intel, new noncoherent DMA mem flag can be set to allow KVM to
recognize guest cache setting for EPT, which allows WC attribute to be
applied to ensure guest memory access is synchronized in noncoherent DMA.
Unlike previous POC for new device attribute, this uses new added flag
for mem slot.
BUG=b:316337317
TEST=cargo build and run GPU workload
Change-Id: If16d61031bdb2cf0252a57e99d4b6725a89dd38a
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5171312
Reviewed-by: Frederick Mayle <fmayle@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Stanisław Kardach <skardach@google.com>
Refresh the bindings with newer bindgen, allowing us to get rid of the
clippy errors.
BUG=b:322056705
TEST=boot emulator on HAXM
Change-Id: I1eb455b8fbb39c89c7d9e60a134a305afaa99499
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5232520
Commit-Queue: Idan Raiter <idanr@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
HAXM is incompatible with read-only memslots (we'll need to add
support). Similar to the fix for pKVM, we can disable the feature.
BUG=b:312564055
TEST=emulator works on HAXM
Change-Id: I50938d27aee81fbeec9bb542a88b5e51f473be54
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5226608
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Idan Raiter <idanr@google.com>
Provide more accruate detail in xsave_size comment.
Use .max as suggested by fmayle@, looks neat!
BUG=N/A
TEST=presubmit
Change-Id: Ic2b1dddc7e8aa531a884aee5e36ccc15a92eceb2
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5191638
Commit-Queue: Elie Kheirallah <khei@google.com>
Auto-Submit: Elie Kheirallah <khei@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Some MSRs are introduced in newer CPUs but are not directly supported by
kernels/OSes. On creation of the VM, we are not modifying those MSRs.
When we snapshot, get_all_msrs will return all available MSRs, and this
would get us the newly introduced MSRs.
The issue occurs when we try to set those MSRs.
This has been observed in certain environments while using AOSP.
Add an allowlist that contains these MSRs and only throw warnings if we
try to set those MSRs. If an MSR is not in the allowlist and fails to be
set, an error will be thrown.
Restore MSRs 1 at a time to go over all of the list regardless of
hypervisor behavior (KVM tries to restore until failure, WHPX restores
multiple at the same time, HAXM restores 1 MSR at a time).
BUG=b:316912197
TEST=tested in AOSP, presubmit
Change-Id: If2455858c2969c50f456bfa8ba96a934c97d5a41
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5187926
Auto-Submit: Elie Kheirallah <khei@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Elie Kheirallah <khei@google.com>
pKVM doesn't support read-only memslots (even for non-protected VMs,
though that may change eventually). Based on what I know, I assume
geniezone and gunyah have similar limitations, but I didn't verify.
BUG=b:316956218
TEST=patched into AOSP and started pKVM VM
Change-Id: Ic9df33bceedcf807a04beae8e4d25543784a0986
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5171308
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Frederick Mayle <fmayle@google.com>
Reviewed-by: David Stevens <stevensd@chromium.org>
Similar to
https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5085548,
Xsave2 may not be supported and would return 0. In that case, Xsave max
value sohuld be used.
BUG=b:316912197
TEST=tested in AOSP + presubmit
Change-Id: Ie35f92a10699aae20f4dbbc07fe0bf1fbb57881d
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5187098
Reviewed-by: Steven Moreland <smoreland@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Frederick Mayle <fmayle@google.com>
Auto-Submit: Elie Kheirallah <khei@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Elie Kheirallah <khei@google.com>
gdbstub 0.6.3 -> 0.7.0
gdbstub_arch 0.2.4 -> 0.3.0
There is small change in API, see src/crosvm/gdb.rs. `read_addrs` now returns a `usize` instead of a `()`.
This change is needed to submit this AOSP topic: https://android-review.git.corp.google.com/c/platform/external/crosvm/+/2879249
BUG=b:286979636
TEST=tools/presubmit --all
Change-Id: I124d65e673c5943070c2bb5e39e3a7e5506e5528
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5146447
Commit-Queue: Frederick Mayle <fmayle@google.com>
Reviewed-by: Vikram Auradkar <auradkar@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
KVM_CHECK_EXTENSION will return 0 if XSAVE2 is not available.
fmayle@ had noticed that we are creating Xsave with size 0, which would
be an error.
Check if size == 0, and if so, set it to Xsave max size.
BUG=N/A
TEST=AOSP TH
Change-Id: I10c7344aae1005bab2981fbeaf2c7906b871594c
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5085548
Auto-Submit: Elie Kheirallah <khei@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Noah Gold <nkgold@google.com>
The TSC itself is saved/restored as a MSR by most hypervisors
(e.g. KVM), so we generally don't need to also save/restore the
TSC offset*; in fact, this could desync TSC and lead to guest time
warping because the TSC offset cannot be set directly (it has to
use a host TSC reference moment). However, some hypervisors need
to use the TSC offset to fix up timekeeping in concert with
virtio-pvclock.
This CL does several things to resolve these issues:
1. Stop always restoring TSC offset.
2. Provide a new method for hypervisors to implement their own
behavior with TSC offset & restoring timekeeping.
3. Take a common host TSC reference moment and provide it to the
timekeeping restore method.
* We later discovered KVM's pvclock seems to not be working correctly if
we stop restoring the TSC offset. It seems that setting TSC_KHZ via
the KVM API somehow fixes the issue as well. Further investigation is
needed to understand why. For the time being we're going to keep the
existing TSC offset restore behavior.
Thanks to colindr@ for a ton of help debugging & understanding the
underlying timekeeping problem and hypervisor oddities.
BUG=b:311314468
TEST=tested on WHPX.
Change-Id: Ib2196085061f57931362b3d5da2383bc5e1abbe7
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5042037
Commit-Queue: Noah Gold <nkgold@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Colin Downs-Razouk <colindr@google.com>
Reviewed-by: Frederick Mayle <fmayle@google.com>
Sometimes we need to directly set a TSC value rather than an offset;
for example, when restoring from a snapshot. This CL introduces a
new Vcpu function for this, set_tsc_value.
Here, we are also removing an old WHPX call to set TSC offsets that
appears to no longer work.
BUG=b:311314468
TEST=ran on WHPX & verified guest timekeeping is working when using this
function on snapshot restore.
Change-Id: I05020711a61a6dc2a82ef009089266724f2d92f4
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5042036
Reviewed-by: Elie Kheirallah <khei@google.com>
Commit-Queue: Noah Gold <nkgold@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Frederick Mayle <fmayle@google.com>
base::Pid is explicitly added since every platform has a process id
type.
Bug: 233233301
Test: tools/dev_container ./tools/presubmit
Change-Id: Id0d54fe06981c1dcbdee3f73b1241af74a26300f
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4909061
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Cody Schuffelen <schuffelen@google.com>
To make updating nodes and node properties easier, this change
restructures the internals of the Fdt struct. The single binary blob
that made up the contents of the FDT binary is replaced with with a tree
structure of `FdtNodes`.
This change allows adding new nodes and properties nested inside an
existing node structure. With prevous implementation which kept FDT data
stored in its binary form, inserting nodes and properties would require
a lot of byte shifts and lookups. These changes will make applying FDT
overlays much easier.
The API is also simplified, writing properties after adding subnodes is
no longer an error, and the concept of "opening" and "closing" FDT nodes
is no longer used.
Bug: b/296796644
Test: cd cros_fdt && cargo test
Change-Id: I1ad90771c0a4a0bb29f0322773d55c82d4cd5575
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4916796
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Jakob Vukalović <jakobvukalovic@google.com>
Modifying FDTs and applying overlays will require additional APIs to
read property values. Ideally, we want to avoid implementing a new
getter method for each supported property value type, and instead have
a single `get_prop` method, and the same for alreaddy existing setters.
Therefore, before implementing property value getters, this change
replaces the seven setter methods for each supported property value
type with a single `set_prop` method taking a type which implements
`ToFdtPropval` trait. Also, implement the trait for each supported type.
Bug: b/296796644
Test: cd cros_fdt && cargo test
Change-Id: Iac05b4b2064d98657e19058fa25ffc689789c8b3
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4916795
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Jakob Vukalović <jakobvukalovic@google.com>
Currently crosvm has no support for generating device tree nodes for
platform devices assigned via VFIO. That limits usage of platfor VFIO
devices in VMs.
Additional DT nodes can be added to the DT via the overlay mechanism.
This and the following patches add support for amending the VM device
tree by adding support for device tree overlays.
As the first step, rename the FdtWriter struct to Fdt. It makes sense
to use a more general name as the crate gains additional features.
Bug: b/296796644
Test: cd cros_fdt && cargo test
Change-Id: Id6b943f23f7d89151dc66565f694eb0f988265d2
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4855960
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Jakob Vukalović <jakobvukalovic@google.com>
Updates are made to source and documentation.
This more accurately represents the currently supported platforms of
Android/Linux and Windows, without unexpectedly including other
unix-like operating systems.
Command to reproduce:
$ find . -type f -not -path '*/\.git/*' | xargs -I {} sed -i 's/cfg(unix)/cfg(any(target_os = "android", target_os = "linux"))/g' {}
$ cargo fmt
md files manually updated to fix line lengths.
Renaming `unix` modules to `linux` will be done in a later CL.
Test: ./tools/dev_container ./tools/presubmit
Bug: b/298269162
Change-Id: I42c1bf0abf80b9a0df25551613910293217c7295
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4909059
Commit-Queue: Cody Schuffelen <schuffelen@google.com>
Reviewed-by: Frederick Mayle <fmayle@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Noah Gold <nkgold@google.com>
As usual, some unsorted and grouped imports have appeared.
Change-Id: I79b51e4c52cee38f5b8c238e46dfe3193c753554
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4847980
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Restoring a snapshot on WHPX was failing with a SMP Linux guest. khei@
noticed that WHPX has a special "internal" register called
WHvRegisterInternalActivityState. This register is not in the Hypervisor
Top Level Specification, but it does appear in the WHPX headers & MSDN
docs. Its exact function is not specified, but by experimentation we
believe it contains state critical for SMP guests to restore
successfully (they restore successfully once this register is
saved/restored). Perhaps there is some IPI or kernel side LAPIC state
that is only available via this register, and that state is only
critical for SMP guests. In any event (pun intended), we treat the
register as opaque data, and that seems to work fine.
This CL also adds another register that we previously skipped over,
WHvX64RegisterDeliverabilityNotifications. This register is how we
request an interrupt injection window from WHPX for things like PIC
interrupts. Previously we weren't saving/restoring it, and it's possible
for such a request to be pending at snapshot time, so we shouldn't be
discarding that state as it could break things.
BUG=b:297294476
TEST=snapshotted & restored an Ubuntu SMP guest successfully.
Change-Id: I65c14432c9a56388bda7edeacfa21fe1fa8951a6
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4827931
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Noah Gold <nkgold@google.com>
Reviewed-by: Elie Kheirallah <khei@google.com>
It turns out the TSC adjust register in the VMCS is already handled for
us by the generic x86_64 code. Actually trying to restore the TSC MSR
will clobber that in a way do not want. (Our goal in snapshotting for
WHPX is to ensure that TSC adjust remains the same, not that the guest's
views a TSC that does not change across snapshot/restore. We rely on
virtio-pvclock to fix up the guest clock after the restore operation,
and it requires TSC adjust to remain constant.)
BUG=b:297294476
TEST=ran the emulator and snapshotted with pvclock enabled. The kernel
did not complain about clock issues.
Change-Id: I04306339d6c11a094d2c81a13f225927b9a89911
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4827930
Reviewed-by: Elie Kheirallah <khei@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Noah Gold <nkgold@google.com>
This option was only used by crosvm_direct, which has been removed, and
there are no other tests for this functionality. Remove the dead code
before it bitrots.
BUG=b:279663365
TEST=tools/dev_container tools/presubmit
Change-Id: Ie3b33a5133dafc2425184092179c08455c02fd21
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4811782
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
crosvm has never actually supported running on a 32-bit x86 host, only
x86-64. Remove the cfg(target_arch = "x86") checks throughout the tree
to make this clear (and to simplify the code).
This doesn't affect the code running inside the guest, which can still
be a 32-bit x86 operating system if launched via --bios, for example.
BUG=None
TEST=tools/dev_container tools/presubmit
Change-Id: Ifd888db54c58ec8a5fcf840871ef564771d9066b
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4794387
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Zihan Chen <zihanchen@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
