For ioctl numbers that do not require any parameters, make ioctl_io_nr
and related macros generate a constant rather than a function with no
parameters. This makes the code that uses these constants more idiomatic
and also allows using the constants in match statements (see an example
in virtio/fs/passthrough.rs).
BUG=None
TEST=tools/dev_container tools/presubmit
Change-Id: Id52817528d770c5dbbe2ce7928c9f31a15c83d83
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5648647
Reviewed-by: Noah Gold <nkgold@google.com>
Reviewed-by: Frederick Mayle <fmayle@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Test verifies that xsave saves/restores SSE state as expected inside the
guest.
BUG=b:333888472
TEST=presubmit
Change-Id: Ia363ebc27cd7afeb22aff3485293d2a635bf7d4c
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5655390
Reviewed-by: Judson Powers <judsonp@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Noah Gold <nkgold@google.com>
This ensures that the FPU registers are correctly limited to the 80-bit
representation (previously, they were represented as 16-byte/128-bit
values), as well as making it possible to implement helper functions for
the type.
BUG=b:347983128
TEST=tools/dev_container tools/presubmit
Change-Id: I361830d2c9c480cebdb0157b130abd18b4f2235f
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5640380
Reviewed-by: Noah Gold <nkgold@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
When the guest hits a vmexit, the hypervisor must preserve guest
register state, including MMX registers. This test verifies that the
hypervisor is correctly preserving one of the MMX registers. Since these
registers are generally preserved in a single block (e.g. with fxsave,
xsave, xsaves), testing a single register is sufficient.
BUG=b:333888472
TEST=presubmit
Change-Id: I728ddd2060ec298831c669442c540aa2d8fdd55b
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5631973
Commit-Queue: Noah Gold <nkgold@google.com>
Reviewed-by: Idan Raiter <idanr@google.com>
Reviewed-by: Judson Powers <judsonp@google.com>
Reviewed-by: Oystein Eftevaag <oysteine@chromium.org>
Under the hood, both AMD [1] and Intel [2] only accept 8 bit vector for event injection, so it's highly likely that all hypervisor implementation to encounter an error when we pass in values greater than 0xff as the vector.
From the source we can tell that KVM rejects any value greater than 0xff, HAXM has some strange unwanted behaviors with invalid vector values. From testing, we can tell WHPX also rejects invalid vector values right away.
[1]: Figure 15-5. EVENTINJ Field in the VMCB of AMD64 Architecture Programmer’s Manual, Volumes 2.
[2]: Table 25-17. Format of the VM-Entry Interruption-Information Field of Intel 64 and IA-32 Architectures Software Developer's Manual Volume 3.
TEST=./tools/dev_container cargo nextest run --workspace --profile=default -E 'package(hypervisor) & binary(hypervisor_virtualization)' --retries 0 --no-capture
BUG=b:334055761
Change-Id: Ied118f0df10e4a1c973b5b26327c24f45064d56c
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5602270
Commit-Queue: Kaiyi Li <kaiyili@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Judson Powers <judsonp@google.com>
For emulated instructions, the hypervisor normally needs to intercept
the instruction, emulate it and advance the rIP afterwards. This test
makes sure that the interruptibility is correctly handled in this case.
Particularly, if an instruction is emulated after an sti when FLAGS.IF
is cleared or a mov ss, after the emulation. The interruptibility should
be restored.
Change-Id: Ib1e897b5d4dd97b2877814a6e7bff56e222d13d2
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5610292
Reviewed-by: Judson Powers <judsonp@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Kaiyi Li <kaiyili@google.com>
This test ensures that we don't deliver an interrupt if the guest is not
interruptible even when we call vcpu.interrupt() with
vcpu.ready_for_interrupt() returning false.
Below is the actual behaviors of different hypervisors, but our test
doesn't test against specific behaviors:
* For KVM, the interrupt injection succeeds, but the following VCPU run
fails
* For WHPX, the interrupt injection fails as if we never try to inject
the interrupt.
* For HAXM, the interrupt will be pending and will be delivered once the
interrupt is reenabled.
TEST=./tools/dev_container cargo nextest run --workspace --profile=default -E 'package(hypervisor) & binary(hypervisor_virtualization) & test(test_interrupt_injection_when_not_ready)' --retries 0 --no-capture
BUG=b:334055761
Change-Id: I06d6f662457860a6fc1b2c7a657dfb42bb3c9b07
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5584661
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Judson Powers <judsonp@google.com>
Commit-Queue: Kaiyi Li <kaiyili@google.com>
* cli to disable interrupt
* use out to cause a VMEXIT and request an interrupt window
* sti to reenable the interrupt
* test whether we receive a VMEXIT for interrupt window
TEST=./tools/dev_container cargo nextest run --workspace --profile=default -E 'package(hypervisor) & binary(hypervisor_virtualization)' --retries 0
BUG=b:334055761
Change-Id: Idf04a7e3d85dff32b5a5f8d590cbb852bbe58ec9
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5599545
Reviewed-by: Judson Powers <judsonp@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Kaiyi Li <kaiyili@google.com>
It is necessary to test set_interrupt_window_requested on HAXM, which
doesn't distinguish between VcpuExit::Intr and VcpuExit::IrqWindowOpen.
TEST=./tools/dev_container cargo nextest run --workspace --profile=default -E 'package(hypervisor) & binary(hypervisor_virtualization) & test(test_interrupt_injection_when_not_ready)' --retries 0 --no-capture
BUG=b:334055761
Change-Id: I1969d0bb25c7580a14de749a99805cdf9d96e48d
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5599544
Reviewed-by: Judson Powers <judsonp@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Kaiyi Li <kaiyili@google.com>
These don't need to be try_from(), since the destination type can
represent all possible values of the source type.
Fixes upcoming clippy infallible conversion warnings.
BUG=b:344974550
TEST=tools/clippy
Change-Id: I6fab70ef0888a66c0d5464a64f9daf28d4e3741e
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5597966
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Noah Gold <nkgold@google.com>
Transmuting from [u8; 16] to [u32; 4] was undefined behavior, since the
alignment of u32 is larger than that of u8.
Replace this conversion, as well as the corresponding conversion back to
an array, as `from_ne_bytes()` and `to_ne_bytes()` functions as wrappers
around the standard `u128` functions by the same names, and implement
`u128` <-> `WHV_UINT128` conversions in a safe, straightforward way
with casts of the union fields to the appropriate native types and
shifting.
BUG=None
TEST=tools/presubmit_clippy_mingw64 # with whpx feature
Change-Id: I4e3fa84ade61c7da6e66f3dbf6a110e81bf8b1fa
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5577447
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Noah Gold <nkgold@google.com>
It is only guaranteed that interrupt won't be delievered right after sti
only when FLAGS.IF is not set. With the added cli, all hypervisors don't
allow interrupt injection right after sti.
TEST=./tools/dev_container cargo nextest run --workspace --profile=default -E 'package(hypervisor) & binary(hypervisor_virtualization)' --retries 0 --no-capture
BUG=b:334055761
Change-Id: Ie7a5cc9ca7e4a597c6fe07b59772a1380b64d858
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5578134
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Judson Powers <judsonp@google.com>
Commit-Queue: Kaiyi Li <kaiyili@google.com>
The interrupt window includes:
* sti
* mov ss
On real x86 processors, after certain instructions(mov ss/pop ss/sti), an interrupt is guaranteed not to be delivered for exactly one instruction, not just an indefinite amount of time.
For mov ss/pop ss, this is architecturally defined so that loading a new stack segment plus stack pointer together can be done atomically (without an interrupt handler running in the middle and using a half-initialized stack address).
For sti, this delay allows the kernel to do sti ret, without an interrupt handler running before we return from the current routine.
However, the virtualization instructions allow the hypervisor to inject interrupts. Therefore, it's the hypervisor/VMM's responsbility to not to deliver an interrupt on an unexpected places on the guest.
This test uses port IO to trigger VMEXIT before and after mov ss or sti, and tests the interruptibility under different occasions. It also tests when the interrupt will be delivered.
TEST=./tools/dev_container cargo nextest run --workspace --profile=default -E 'package(hypervisor) & binary(hypervisor_virtualization) & test(interruptible)' --retries 0 --no-capture
BUG=b:334055761
Change-Id: Ib800c5e8054b4bcc4b20899d2cea1b113081c0e7
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5568137
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Kaiyi Li <kaiyili@google.com>
Reviewed-by: Judson Powers <judsonp@google.com>
* Create different ISRs that set different registers for interrupt 32
and 33.
* Set up the IDT.
* hlt on the guest to allow the test to inject both the interrupt 32 and
33.
* hlt again on the host to end the guest VM.
* Check the registers on the host to verify which ISR has been called.
TEST=./tools/dev_container cargo nextest run --workspace --profile=default -E 'package(hypervisor) & binary(hypervisor_virtualization)' --retries 0
BUG=b:334055761
Change-Id: I7aa649542f81b346f7334cbdec1092986afead35
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5550432
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Judson Powers <judsonp@google.com>
Commit-Queue: Kaiyi Li <kaiyili@google.com>
This will fix inconsistency between the assemblies in the comments and
the actual machine code.
TEST=./tools/dev_container cargo nextest run --workspace --profile=default -E 'package(hypervisor) & binary(hypervisor_virtualization)'
BUG=b:334055761
Change-Id: Ia2a7c86305fd3f6977a51729a1a3bfd462547777
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5556303
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Oystein Eftevaag <oysteine@chromium.org>
Commit-Queue: Kaiyi Li <kaiyili@google.com>
Reviewed-by: Judson Powers <judsonp@google.com>
Fills in the vcpu panic reason for haxm. Also consumes that panic reason
in logging for Windows.
BUG=b:340719884
TEST=ran emulator with ghaxm hard coded to panic.
Change-Id: I775ead90319c3c1fabcc6d51fdea4dd3d94099ff
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5550445
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Judson Powers <judsonp@google.com>
Commit-Queue: Noah Gold <nkgold@google.com>
We made some adjustments to how the panic reason will be communciated
via the hax_tunnel.
BUG=b:340719884
TEST=builds
Change-Id: I37195d844c4bde6404b64ae85a160c0fdebbf746
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5556522
Reviewed-by: Judson Powers <judsonp@google.com>
Commit-Queue: Noah Gold <nkgold@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Ensure that every Cargo.toml dependency on a third-party crates.io crate
specifies at least a major version, or a minor version for 0.x crates,
to ensure that if a new major version is published, it cannot cause API
breaks.
The versions are selected to match the ones already in Cargo.lock, so
this should have no functional change, but it will help prevent new "*"
versions from being introduced via copy-and-paste.
For rationale, see the Cargo FAQ:
<https://doc.rust-lang.org/cargo/faq.html#can-libraries-use--as-a-version-for-their-dependencies>
`minijail`, `audio_streams`, and `cras` are left as "*" for now, since
they have unusual situations (imported from a submodule and/or replaced
at build time with ebuild magic).
BUG=None
TEST=tools/dev_container tools/presubmit
TEST=verify Cargo.lock is unchanged
Change-Id: Ifa18199f812f01d2d10bfb4146b3353c1a76527c
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5555656
Reviewed-by: Frederick Mayle <fmayle@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
This test:
* sets the IDT
* sets one register in the ISR
* uses hlt to VMEXIT
* inject an interrupt through the hypervisor
* check if the ISR has executed by checking the register
TEST= cargo nextest run --workspace --features=all-msvc64_product_debug_test,whpx --profile=default -E 'package(hypervisor) & test(/.*test_minimal_interruption_injection/)'
BUG=b:334055761
Change-Id: Id082d5b48434745e12ac3467f37de45bdb22b669
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5548947
Commit-Queue: Kaiyi Li <kaiyili@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
The XGETBV instruction returns the value in EDX:EAX, and we want to pass
that value unmodified to XSETBV, but the code that enables CR4.OSXSAVE
is clobbering EAX in between the two instructions. Move XGETBV right
before XSETBV so the value is not modified.
BUG=b:333925394
TEST=tools/dev_container tools/presubmit
Change-Id: Ic71024b89dadc45cf729fd51d4cc0f3c1e00600b
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5548436
Reviewed-by: Richard Zhang <rizhang@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Oystein Eftevaag <oysteine@chromium.org>
The new global_asm_data macro allows to embed the compiled assembly as an array, which makes it easier to modify and write new integration tests for the hypervisor.
A proc-macro is needed to generate random symbols and forward arbitrary arguments to the global_asm! macro.
TEST=cargo test --doc --package hypervisor_test_macro
TEST=cargo nextest run --workspace --features=all-msvc64_product_debug_test,whpx --profile=default -E 'package(hypervisor) & test(/.*test_minimal_virtualization/)'
BUG=b:334055761
Change-Id: I83b4b5f46bdd39adbfd279fefabbf275eb6127ea
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5549033
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Judson Powers <judsonp@google.com>
Commit-Queue: Kaiyi Li <kaiyili@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
VcpuExit::Shutdown is essentially the hypervisor notifying the VMM that
something has gone badly wrong. The trouble with it is that "something"
could be a lot of different things. This CL expands the Shutdown
discriminant to include a failure code which can be filled in by the
hypervisor.
BUG=b:340719884
TEST=builds
Change-Id: I390940bd6eb77ffafe7e2c43a05b318f3736218c
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5548454
Reviewed-by: Judson Powers <judsonp@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Noah Gold <nkgold@google.com>
Vcpu panics now generate detailed panic reasons via the hax_tunnel. This
CL pulls in the bindings we need to access those reasons. It also pulls
in a refactor that renames variables on the haxm side (underscore has
been dropped from struct fields).
BUG=b:340719884
TEST=builds
Change-Id: I94ea104dd790684c88c8a4aab6a30036d238351f
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5550442
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Noah Gold <nkgold@google.com>
Design doc: go/arcvm-virtual-swap-impl
BUG=b:329310285
TEST=./tools/dev_container ./tools/presubmit
TEST=crosvm run with virtual swap options, set up the pmem device as an
swap area, verify the swapped in memory from guest are released from the
host swap.
TEST=crosvm run --pmem file.img, verify file size is 0 with
blkdiscard(8) from the guest that discards the whole file
Change-Id: Ie8f2910886ea754b9490fe5e762b578ca9d20a24
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5531228
Reviewed-by: Takaya Saeki <takayas@chromium.org>
Commit-Queue: Hung Nguyen <hungmn@google.com>
AMD hypervisors may require and report the presence of this bit, but it is not relevant to the test.
Bug=b:337310339
Change-Id: I0be9ac17ac9630cc2e86b33a9575b730d67c488f
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5546047
Reviewed-by: Noah Gold <nkgold@google.com>
Reviewed-by: Idan Raiter <idanr@google.com>
Reviewed-by: Oystein Eftevaag <oysteine@chromium.org>
Commit-Queue: Judson Powers <judsonp@google.com>
The new options will allow a virtio-pmem to be created based on an
anonymous memory mapping, and can be paged out at the specified
interval. The created virtio-pmem device can be used as a swap area in
the guest, where the guest swapped out memory will be paged out to the
host swap area.
Design doc: go/arcvm-virtual-swap-impl
BUG=b:329310285
TEST=./tools/dev_container ./tools/presubmit
TEST=tested seccomp policy with armv7-unknown-linux-gnueabihf and
aarch64-unknown-linux-gnu targets running on 32 bit (hana) and 64 bit
(kukui) ARM devices
TEST=crosvm run with new pmem options
Change-Id: Icd261bf94ba9c8168b9274b8e56fe352f153b9e6
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5529961
Reviewed-by: Takaya Saeki <takayas@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Hung Nguyen <hungmn@google.com>
For test_control_register_access_invalid: this test causes an hypervisor fault, change the test to verify that the invalid bit set in CR0 won't be read out again.
For test_xsetbv_instruction: Set the OSXSAVE bit in cr4 before running the test, and
write a value with bit 0 set into XCR0 (needed according to the manual, though the other
hypervisors and KVM in nested mode seems to pass regardless).
Bug: 333925394
Change-Id: Ifef0f031adcb478bd65d5a8472d932d86d65684d
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5537842
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Oystein Eftevaag <oysteine@chromium.org>
When using demand paging, userspace shouldn't provide shm vdevice in the
VM configuration. The shm vdevice is used by RM to automatically accept
and map the mem parcel. With demand paging, the kernel wouldn't be
creating mem parcels and Gunyah complains about that no mem parcel was
provided for the shm vdevice. Gunyah allows us to add "optional" tag to
the vdevice and it will be ignored if no mem parcel is prvoided, as is
the case for demand paging.
We could create additional downstream UAPI to indicate whether demand
paging is being used and not create the vdevice node at all, but the
approach of adding "optional" property was preferred to avoid creating
downstream UAPI.
Bug: 330496811
Change-Id: Ib070e9d453af88a7af5f8c240f9a22c7b744c987
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5541239
Commit-Queue: Frederick Mayle <fmayle@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Read the updated DR2 value back into a different register (RBX) than the
one that is initialized with the value to write (RAX) so that the test
actually verifies that reading the debug register worked (rather than
just looking at the RAX value that could be left over from initialization).
Also fix the assembly mnemonics in the comments: the encoded
instructions access DR2, not DB2.
Change-Id: I0b934ce9a1f80093263678d1f50b3d229c30260c
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5537840
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Noah Gold <nkgold@google.com>
Reviewed-by: Oystein Eftevaag <oysteine@chromium.org>
Covers most of the instructions that may require special handling.
The tests don't necessarily test for outcomes, but for now will
at least exercise the handlers.
Change-Id: I4427fdfd4625da3a0f034bcfb12be7707d256e8d
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5483708
Reviewed-by: Judson Powers <judsonp@google.com>
Commit-Queue: Oystein Eftevaag <oysteine@chromium.org>
Reviewed-by: Noah Gold <nkgold@google.com>
When kvm clock is available, Linux (6.1 at least) uses it for the
scheduling clock (among other things) even when the TSC is configured as
the primary clock source. When restoring a VM, if we don't make a
KVM_SET_CLOCK call, kvm clock's value will rollback to zero and cause
trouble.
`ClockState::flags` was deleted because it had no existing uses, it
isn't useable in any hypervisor generic way, and because it will result
in incorrect behavior for snapshotting. The set of valid flags returned
by KVM_GET_CLOCK is not the same as the set of valid flags that can be
passed to KVM_SET_CLOCK.
Bug: 339527192
Change-Id: I57503e72499a44e98e0c6ca93eb8cb01cb21c16d
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5530677
Reviewed-by: Elie Kheirallah <khei@google.com>
Commit-Queue: Frederick Mayle <fmayle@google.com>
Duplicate the KvmCap enum and KvmCpuId type alias that were imported
from the top-level `kvm` crate in order to drop the hypervisor -> kvm
dependency.
The `kvm` crate is otherwise only used by the plugin feature, so this
removes it from the build in the usual non-plugin case.
BUG=None
TEST=tools/dev_container tools/presubmit
Change-Id: If710c547619f7c2bbff7e0a6eeca7a6aaf19e63c
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5517747
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
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>
Timekeeping on WHPX under CrosVM is handled by virtio-pvclock. This
device depends on the delta between the host & guest TSC (TSC
offset MSR in VMCS/VMCB) being the same at snapshot & restore time.
Previously we weren't saving/restoring this MSR. This CL adds it to
the list of MSRs we save/restore.
BUG=b:294134741
TEST=ran busybox image, verified save/restore work.
Change-Id: Ic5cff8412f1f11da31ff85acc268a8907c80bf34
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4779855
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Frederick Mayle <fmayle@google.com>
Commit-Queue: Noah Gold <nkgold@google.com>
