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>
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>
