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>
When snapshotting, the interrupt state (pending or otherwise) needs to
be saved from the VCPU. Every hypervisor has its own implementation
of how this is exposed to VMMs (KVM uses vcpu_events). This CL adds
an implementation for WHPX's VCPU.
BUG=b:270734340
TEST=builds (we can't test the full WHPX snapshot flow yet; need to
reach critical mass on implementation first).
Change-Id: Ic97ad15391f277967bd7b19a7ff6b55c57f3a00b
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4428057
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Elie Kheirallah <khei@google.com>
Reviewed-by: Vaibhav Nagarnaik <vnagarnaik@google.com>
Commit-Queue: Noah Gold <nkgold@google.com>
EIO is more appropriate than unsupported for this error.
BUG=b:270734340
TEST=builds
Change-Id: Idaf8c291c7301f1ee929aafc12bf032f19d71e35
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4425875
Commit-Queue: Noah Gold <nkgold@google.com>
Reviewed-by: Vikram Auradkar <auradkar@google.com>
Originally VcpuEvents was modeled on KVM's vcpu_events struct. Other
hypervisors like WHPX represent the sort of data that's in KVM's struct
very differently. This CL moves us to use a json blob that each
hypervisor can define for itself, which unblocks implementing for WHPX.
BUG=b:270734340
TEST=tools/dev-container e2e_tests/run
Change-Id: I1600f4303ee5bf2aebeaeb92a215edaea2f69a87
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4421490
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Elie Kheirallah <khei@google.com>
Commit-Queue: Noah Gold <nkgold@google.com>
MSR index 0x3f1 (MSR_IA32_PEBS_ENABLE) is now allowed to be fetched by
KVM_GET_MSRS in newer kernels.
Pick an even more invalid MSR index so the MSR will actually fail to be
fetched.
BUG=b:275605159
TEST=cargo test -p kvm -p hypervisor # on Linux 6.1
Change-Id: Ia4f34ca43893535883620e82f35a955e630a9743
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4419606
Auto-Submit: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
I suggested a workaround to make Xsave data 4-byte aligned for KVM while
representing it equivalent to a Vec<u8>, but the suggestion was
incorrect - the workaround made each XsaveByte one byte of data and
three bytes of padding, which was not intended.
Partially revert the representation of Xsave to a Vec<u32>, but keep the
Xsave::new() function so the caller does not need to know about the
internal representation.
BUG=b:270734340
TEST=tools/dev_container tools/presubmit
Change-Id: I5d51f02d4fee061840d591a9ef16a78f44274064
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4412666
Reviewed-by: Noah Gold <nkgold@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
get/set_xsave lets us get/set the xsave data on a VCPU. Originally this
was set to be represented as Vec<u32> since that's what KVM uses on its
ioctl; however, other hypervisors like WHPX prefer an opaque byte array.
This CL switches us to a byte array. From KVM's perspective, this is
identical because we still require a 4 byte alignment.
BUG=b:270734340
TEST=builds
Change-Id: Ia7931f0f07e5e95beab39f65ad1a5942ad9841f6
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4410240
Commit-Queue: Noah Gold <nkgold@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Steven Moreland <smoreland@google.com>
Implement base gunyah abstractions.
Bindings are based off aosp/2475305/9.
Cherry-pick notes: Fixed license headers and uppercased bindgen constant
to workaround "constant in pattern ... should have an upper case name"
warning that can't be disabled (will need to adjust the bindgen script
later to match).
BUG=b:232360323
Change-Id: I4815128ce827112b25add87ac11e28868b4cdb46
Co-developed-by: Sreenad Menon <quic_sreemeno@quicinc.com>
Signed-off-by: Sreenad Menon <quic_sreemeno@quicinc.com>
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4404217
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Enable gunyah feature for all-aarch64. all-x86_64 inherits all-aarch64
and Gunyah does not support x86_64, so create a new meta-feature,
all-default to support the common features that need to be enabled in
aarch64 and x86_64.
Cherry-pick notes: This commit now adds the "gunyah" feature and is
moved earlier in the series so that changes later in the series can be
properly tested by presubmits.
BUG=b:232360323
Change-Id: Ibb3b0ad48017c2480498634d766aea162114b385
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4404216
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Gunyah initializes at VM level, not the vCPU level as KVM. Add
VM-generic initialization which happens after build_vm, but before the
VM starts to run.
BUG=b:232360323
Change-Id: Iea38cf63eca9b525e613450fd7bca2d422923063
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4400669
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
