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>
In Vcpu::on_suspend for WHPX, we were calling WHvSuspendPartitionTime
which didn't make sense for several reasons:
* on_suspend is intended to help with guest timekeeping. We don't need
this on WHPX because the clock is managed via virtio-pvclock.
* WHvSuspendPartitionTime is a partition (read: VM) wide operation.
That means it should be called once on the VM, not on every VCPU.
Calling it on every VCPU yields errors on subsequent VCPUs.
BUG=b:294134741
TEST=ran virtio-pvclock enabled VM across a S3 and S4 host suspend. No
complaints from the guest kernel in the serial logs.
Change-Id: Ic5f71d277bf393db74e809cf8e0de3d95b4f895b
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4752840
Reviewed-by: Colin Downs-Razouk <colindr@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Noah Gold <nkgold@google.com>
When the guest executes a repeated string I/O instruction like REP INSB
or REP OUTSB, crosvm would previously treat this as one giant I/O,
combining the size of the access (1 for INSB, 2 for INSW, etc.) and the
count (the CX/ECX register when using the REP prefix) into a single size
and called the BusDevice's read() or write() function with this combined
size. However, this doesn't match the expected behavior for the repeated
string I/O instructions - they copy each data unit to/from sequential
memory locations, but they should repeatedly access the *same* port
rather than a series of sequential ports. This information was lost in
the original implementation since `count` was multiplied into `size`.
The broken behavior can be reproduced when using the Linux kernel's
fw_cfg driver, which calls the `ioread8_rep()` function that uses a
`REP INSB` instruction on x86. With the previous crosvm implementation,
when the guest tries to read (for example) 4 sequential bytes from I/O
port 0x511, the crosvm fw_cfg device's read() implementation would be
called with size = 4, even though the data register is only meant to be
a single byte wide.
This patch changes the behavior so that I/O exits with count > 1 will
call the device's read()/write() function repeatedly with the same
address (`count` times), always using the original `size`, e.g. 1 byte
for REP INSB. The hypervisor code handles copying the data into the
right part of memory, so the device implementations don't need to do
anything special to handle the repeated access (it will appear to be
several individual IN/OUT accesses from the device's point of view).
BUG=b:283990685
TEST=tools/dev_container tools/presubmit
TEST=Access fw_cfg sysfs files using crrev.com/c/4702071
Change-Id: If8e520cb3f32a3e0a664a09bfd8884fd92521a67
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4701634
Reviewed-by: Sebastian Hereu <sebastianhereu@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
This is not in upstream Linux, only used by crosvm-direct, which is
being removed. Partially reverts commit f622e504d3 ("crosvm/kvm:
enable runtime detection of IOAPIC pins").
BUG=b:276993009
BUG=b:279663365
TEST=tools/dev_container tools/presubmit
Change-Id: I2d6501a268c635145d8cd25944b5c82fc82b4ec4
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4615556
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Change the function name from pvclock_ctrl() to on_suspend() to make it
less confusing, and make the Vcpu figure out whether any work is
actually needed internally instead of making the caller check a
capability. This means that Vcpu::on_suspend() will always be called,
but most implementations will just do nothing (only KVM on x86 and WHPX
implement an on_suspend that actually takes action for now).
BUG=None
TEST=tools/dev_container tools/presubmit
Change-Id: Ib654d4ca9494e3c951968d1b980d38238d6818d2
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4652557
Reviewed-by: Frederick Mayle <fmayle@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
add a new event from balloon device to the hypervisor to indicate when
the requested balloon size has been reached. this will tell the
hypervisor that balloon is not going to change the page states anymore.
Bug: b:267051826
Signed-off-by: Vaibhav Nagarnaik <vnagarnaik@google.com>
Change-Id: Ie0be0b6293b7e4f4e1591050307f55501bd8c80b
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4602918
Reviewed-by: Noah Gold <nkgold@google.com>
remove `handle_inflate` and `handle_deflate` methods from the trait Vm
and replace with a single `handle_balloon_event` method. this will allow
more balloon events to be handled through the `enum BalloonEvent`.
the change is refactoring and a no-op.
Bug: b:267051826
Signed-off-by: Vaibhav Nagarnaik <vnagarnaik@google.com>
Change-Id: Ia5436eb3b72d6081ac3c05ae461eeb426e5f783c
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4601859
Reviewed-by: Vikram Auradkar <auradkar@google.com>
Reviewed-by: Noah Gold <nkgold@google.com>
The previous VcpuSignalHandle code used a weak reference to the Arc that
was owned by the main Vcpu instance, but this is more complex than
necessary. What we really want to ensure is that the VcpuSignalHandle
has a valid pointer to the memory-mapped VCPU file descriptor, which we
can ensure by tracking the MemoryMapping lifetime inside an Arc and
cloning it to provide the VcpuSignalHandle with a strong reference,
cleaning up some unnecessarily tricky and unsafe code.
BUG=b:285026749
TEST=tools/dev_container tools/presubmit
TEST=boot and shut down ARCVM and Crostini on x86 and arm
Change-Id: Ia15a677a0b6c09eb2e41c4c97d5ba4b4ebf331c3
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4575991
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
The new rust toolchain comes with improved clippy warnings that
catch more unnecessary casts than before.
Some cases have to be whitelisted since libc types have varying size
based on the architecture we are compiling for.
BUG=None
TEST=presubmit
Change-Id: Ia473b0bfe6e74bdb7b0d4ca15d2c9fb410fc353e
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4568144
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
For snapshotting, we want to save/restore *all* MSRs rather
than a one or two specific MSRs. To accomplish this, we're
implementing get_all_msrs for WHPX.
BUG=b:269705560
TEST=unit tests
Change-Id: I706c3bd1d9d11ca58c709e1a19e0184dc560f193
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4546271
Commit-Queue: Noah Gold <nkgold@google.com>
Reviewed-by: Richard Zhang <rizhang@google.com>
Reviewed-by: Frederick Mayle <fmayle@google.com>
After running into issues with MSRs, it seemed advisable to have a smoke
test for these functions too.
BUG=b:269705560
TEST=unit test
Change-Id: I2017dc95c19a7097a4be17099cd33ae75bf7c6f6
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4546270
Commit-Queue: Noah Gold <nkgold@google.com>
Reviewed-by: Vaibhav Nagarnaik <vnagarnaik@google.com>
Reviewed-by: Frederick Mayle <fmayle@google.com>
Reviewed-by: Steven Moreland <smoreland@google.com>
Add snapshot/restore to irqchip for kvm and whpx to save the state of the irqchip.
Add saving apic_base as part of the irqchip.
BUG=b:266515147
BUG=b:232437513
Test=crosvm build - testing requires more changes related to VmRunnableLinux
Change-Id: Iffbd38634390d276d70d6467549df9ffaf176059
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4518572
Commit-Queue: Elie Kheirallah <khei@google.com>
Reviewed-by: Noah Gold <nkgold@google.com>
Reviewed-by: Frederick Mayle <fmayle@google.com>
Auto-Submit: Elie Kheirallah <khei@google.com>
"restricted-dma-pool" was added to the shm-node as a workaround during
initial development of AVF. This workaround is no longer needed and not
used in any deployed devices, so remove it.
BUG=b:232360323
Change-Id: I0be90a7d350d509d5972892cd000868e90572dd9
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4529575
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Auto-Submit: Frederick Mayle <fmayle@google.com>
Commit-Queue: Frederick Mayle <fmayle@google.com>
VcpuRunHandle was only used to signal immediate_exit on unix platforms;
it was unnecessary on Windows. It is replaced with a new
VcpuSignalHandle abstraction that is only implemented for cfg(unix).
This commit moves the thread local storage out of hypervisor and into
the unix/vcpu.rs code; it does not need to be duplicated in each
hypervisor backend.
BUG=b:281723434
TEST=boot crosvm on Linux and Windows
Change-Id: I99491aa3509d86623521298bdcbe5eb9dfcd2d8b
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4382340
Reviewed-by: Noah Gold <nkgold@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Remove the fallback path that supported old KVM versions without
KVM_CAP_IMMEDIATE_EXIT, which has been available since Linux 4.11 /
commit 460df4c1fc7c ("KVM: race-free exit from KVM_RUN without POSIX
signals").
This also removes the need for the Vcpu::set_signal_mask() function, so
it is removed from all hypervisors.
BUG=b:281723434
TEST=boot crosvm on device with 4.14 host kernel
Change-Id: I5329d9b5a6aef6ddac4797aa7ef291df333d27f4
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4382339
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
`get_msrs` truncates the vector on partial success.
Haven't seen this fail. Adding the check as a precaution.
Change-Id: I7c3a4c2408daa9d7a00257ae758da45011a40311
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4515456
Reviewed-by: Elie Kheirallah <khei@google.com>
Commit-Queue: Frederick Mayle <fmayle@google.com>
Reviewed-by: Noah Gold <nkgold@google.com>
This commit reverts 344e2432d1 "x86:
handle KVM_SYSTEM_EVENT_S2IDLE request" but also some other parts which
grow around this concept. The s2idle notification linux counterpart
based on KVM hypercall was rejected in the linux kernel mailing list and
new approach was suggested which is based on virtual PMC. Additionally
the privileged guest term was introduced only for ManaTEE, which is not
evaluated anymore.
The new Virtual PMC related approach is used instead for getting guest
s2idle notifications, see CL:3780642.
BUG=None
TEST=Build + tools/presubmit crosvm_tests_x86_64
Change-Id: I3cf4b77ab192198fe9e8b990b994a41105c2e72f
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4507305
Commit-Queue: Grzegorz Jaszczyk <jaszczyk@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
In preparation for enabling tools/clippy to check riscv, clean up the
warning in the hypervisor crate.
Change-Id: Iab2d1f703e0ab5e40ed165873376cdfabdc3de60
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4505756
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
The KVM docs say
If setting an MSR fails, ..., it stops processing the MSR list and
returns the number of MSRs that have been set successfully.
So, a return value of zero really means the operation completely failed.
Change-Id: Ic98cdb02513ff86e22fb6b048e7ceb2d6b7e554a
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4500732
Reviewed-by: Elie Kheirallah <khei@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Frederick Mayle <fmayle@google.com>
Reviewed-by: Noah Gold <nkgold@google.com>
MSRs are specific to x86/x86-64; add the appropriate cfg checks and
remove the MsrHandlers stubs from aarch64 and riscv64.
Change-Id: I94f0b5b4b9f75fecdc8e03c569f89a70b7f9f647
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4482135
Reviewed-by: Zihan Chen <zihanchen@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
This is a new major version, and requires some code changes.
Change-Id: I294ce3604aad6e6dc5f50e33246b690e883c1e36
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4481294
Auto-Submit: Andrew Walbran <qwandor@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Add basic support for linux kvm running on a riscv64 cpu. Mostly mirrors
the arm support as the interfaces are luckily similar.
Change-Id: I77c091d9b30758788b7c97bc0b3804879e27055d
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4460938
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
