Implement the recent hypercall framework for KVM_EXIT_HYPERCALL, using
the KVM SMCCC filter on AArch64. x86 KVM also supports hypercall
handling in VMMs (currently one) but is left unimplemented for now.
BUG=b:460349550
TEST=tools/presubmit
Change-Id: I28f27dc6433e7681024b284bf2627a038f146c2f
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/7253051
Reviewed-by: Frederick Mayle <fmayle@google.com>
Auto-Submit: Pierre-Clément Tosi <ptosi@google.com>
Commit-Queue: Frederick Mayle <fmayle@google.com>
Add generic support for implementing hypercall handlers in CrosVM.
Introduce the concept of a hypercall bus, enabling handlers to be
presented as devices on that bus, similar to the existing MMIO bus and
IO bus. For now, to enable reusing the internal device look-up logic,
simply introduce the new BusType::Hypercall and the corresponding method
handle_hypercall(). Ideally, this will eventually be cleaned up e.g.
with a separate struct for each bus and a possible shared trait.
Enable full flexibility regarding the hypervisor and CPU in use with the
following indirection:
1. platform-specific exits are converted into VcpuExit::Hypercall
2. Vcpu::handle_hypercall() is called and can populate an
architecture-specific HypercallAbi in a hypervisor-specific way
3. Bus::handle_hypercall() is then called on the result in a generic way
4. the bus looks up the device and calls BusDevice::handle_hypercall()
5. the device can handle the call in a hypervisor-agnostic way, only
having to deal with the ABI, typically through architecture-agnostic
code
This results in device code that can ideally be re-used across
hypervisors and can typically be built for any architecture, removing
the need for more complexity related to conditional compilation.
BUG=b:460349550
TEST=tools/presubmit
Change-Id: Idf59294597d66a91f922ac5e78dae9095e33caea
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/7253050
Reviewed-by: Frederick Mayle <fmayle@google.com>
Commit-Queue: Frederick Mayle <fmayle@google.com>
Auto-Submit: Pierre-Clément Tosi <ptosi@google.com>
This search was implicitly requiring the payload entry point to be at
the start of the region, so I've added an explicit check to maintain
that invariant for now.
Change-Id: I15575a9ea4ad64276f6ec893d66b6be78dd400e1
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/6378535
Reviewed-by: Elie Kheirallah <khei@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Elie Kheirallah <khei@google.com>
Auto-Submit: Frederick Mayle <fmayle@google.com>
The generic function is already available in the current version (0.8.5)
while 0.9.x has deprecated thread_rng and removed OsRng.fill_bytes().
Therefore, use it to replace those (equivalent) to reduce as much as
possible the size of the upcoming CL bumping the dependency version.
Note: No functional change intended.
BUG=b:460349550
TEST=tools/presubmit --all
Change-Id: Ic321aea4595dcc0e087a15b68492686a5c4043c3
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/7209063
Auto-Submit: Pierre-Clément Tosi <ptosi@google.com>
Reviewed-by: Frederick Mayle <fmayle@google.com>
Commit-Queue: Pierre-Clément Tosi <ptosi@google.com>
Halla's kernel dev node name has changed.
Change-Id: Ia7bd28c07a4d62089eeaf691d205595b487cd307
Signed-off-by: Kim Mankyum <mankyum.kim@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/7206166
Reviewed-by: Frederick Mayle <fmayle@google.com>
Reviewed-by: Will Deacon <willdeacon@google.com>
Commit-Queue: Frederick Mayle <fmayle@google.com>
Reviewed-by: Jiyong Park <jiyong@google.com>
To prepare for Rust toolchain uprev, ran `tools/clippy --fix` with
Rust 1.88 for each platform.
To build with the current Rust version 1.81, some changes with unstable
features were manually reverted.
BUG=b:455879436
TEST=CQ
Change-Id: I4a91460d4fc2de5d7afbc2da04b7f7765219bb2e
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/7089630
Reviewed-by: David Stevens <stevensd@chromium.org>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Using the 64-bit KVM API from 32-bit Arm userspace was only possible on
ChromeOS due to a kernel hack that enabled the KVM compat ioctl with no
translation (so it passed through structs directly to the 64-bit host
kernel). This never worked on an unmodified upstream Linux kernel.
All supported Arm-based ChromeOS boards have been migrated to 64-bit
userspace, so we can drop the 32-bit Arm host support code.
BUG=b:452696537
TEST=crosvm CQ
TEST=ChromeOS CQ with crrev.com/c/7094556
Change-Id: I254bc4dbe7f760403cd93f37cc5fdcada23cd483
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/6542041
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Replaces --lock-guest-memory-dontneed (assumed to have no users since it
was just added for Android recently).
`MADV_DONTNEED_LOCKED` doesn't eagerly complete all the steps to free
the memory. In practice, we see that, even though the process' RSS goes
down, the /proc/meminfo memavailable stat doesn't go back up, making it
seem like VMs have a worse overall impact on general memory availability
than is truly the case. Instead, this new option uses `fallocate` with
`FALLOC_FL_PUNCH_HOLE` on the underlying file.
Originally deployed in a hackier form in Android with Change-Id
I872f9051afe165b7e10f8a397792268e158e0e33.
BUG=b:413829005
Change-Id: Ie328b68a43ea689dc626673b43a4aac4ae4ed62e
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/7040142
Reviewed-by: David Stevens <stevensd@chromium.org>
Commit-Queue: Frederick Mayle <fmayle@google.com>
Android has been working around this with code modifications. I'd like
to add this cmdline option so that we can de-fork it.
BUG=b:316956218
Change-Id: I04420b9e1622a7c7e106d4a8e84358953db7e3b5
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/7043165
Reviewed-by: Dmytro Maluka <dmaluka@chromium.org>
Commit-Queue: Frederick Mayle <fmayle@google.com>
Reviewed-by: Elie Kheirallah <khei@google.com>
Off by default until we get some confidence in it.
Tested by enabling in Android Virtualization Framework and booting a
VM on a phone.
BUG=b:216355116
Change-Id: Ife84760d221dcf4dc71c44443a6c481b36380cf1
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/6325390
Auto-Submit: Frederick Mayle <fmayle@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
This is a prereq for KVM_DEV_TYPE_ARM_VGIC_ITS, which will enable MSIs
for aarch64 VMs.
At least for PCI devices, the "device ID" is always the PCI address.
Most of the changes involved plumbing the PCI address around. This is
only needed for aarch64 so far, but I don't want to pollute the code
with too much conditional compilation, so it is done unconditionally and
then ignored inside the hypervisor implementation if not needed.
BUG=b:216355116
Change-Id: I6f5e131c8b7b2fd2575147f1de3a2a87aec8e910
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/6325176
Auto-Submit: Frederick Mayle <fmayle@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Add the size-max property in the vm-config node to let Gunyah
know how big the VM's IPA space could be. Setting it to a large
value of 30GB. If there are any allocations to be done by
Gunyah, it can use addresses after this.
Bug: 417242494
Change-Id: Ieb6779684a4514399f9ddbec2163a9c4eb9dc06c
Signed-off-by: Prakruthi Deepak Heragu <quic_pheragu@quicinc.com>
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/6618133
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Reviewed-by: Elie Kheirallah <khei@google.com>
Reviewed-by: Frederick Mayle <fmayle@google.com>
Commit-Queue: Frederick Mayle <fmayle@google.com>
... so that later it's easier to upgrade the version.
Test: presubmit
Bug: b/417527625
Change-Id: I9626fcea8ae57a2a6671ebbecde7a3de3db7c9ae
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/6604872
Auto-Submit: Kaiyi Li <kaiyili@google.com>
Commit-Queue: Noah Gold <nkgold@google.com>
Reviewed-by: Noah Gold <nkgold@google.com>
As documented, KVM_SET_USER_MEMORY_REGION expects untagged address
Bug: 416181076
Test: use tagged memory for the KVM_SET_USER_MEMORY_REGION
Change-Id: I1a62979a955d5935c4ccc021e57f95fd2c9d0706
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/6518081
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Auto-Submit: Jeongik Cha <jeongik@google.com>
Readonly memslots are generally not supported for protected guests
(pKVM, TDX, SEV), since the host cannot read or write guest memory (so
e.g. with crosvm's use case of optimized exitless PCI config reads,
crosvm wouldn't be able to update the values of PCI config registers in
the mapped memory after the guest modifies those registers), and adding
special cases to support them is considered not worth the extra
complexity.
KVM used to always advertise the KVM_CAP_READONLY_MEM capability on all
architectures supported by crosvm, however since recently it doesn't
advertise it for SEV and TDX guests [1][2] and pKVM on x86 will also
soon disable it for protected VMs [3].
So don't try to use readonly memslots if KVM_CAP_READONLY_MEM is not
advertised. This fixes "Failed to map mmio page; failed to create vm
mapping" warnings when starting a protected VM with pKVM on x86 with
upcoming changes [3] due to trying to set up readonly mappings for the
PCI config.
Note that pKVM on arm64 still doesn't properly return
KVM_CAP_READONLY_MEM=false for protected VMs, however that is addressed
by Android's out-of-tree crosvm patch [4] which is currently needed by
Android anyway, so we don't address arm64 as a special case in this CL.
[1] https://lore.kernel.org/all/20240809190319.1710470-2-seanjc@google.com/
[2] https://lore.kernel.org/all/20240902144219.3716974-1-erbse.13@gmx.de/
[3] dc928a0ee8
[4] https://android-review.googlesource.com/c/platform/external/crosvm/+/2880409
BUG=b:391539939
TEST=protected VMs on x86 start without errors from crosvm or pKVM;
non-protected VMs keep using readonly memslots for PCI config memory.
Change-Id: Iafa0422556f3d4b6928bee636c9e6b1e3a3abcf5
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/6480182
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Dmytro Maluka <dmaluka@chromium.org>
Reviewed-by: Frederick Mayle <fmayle@google.com>
is_pkvm() is supposed to return whether the VM (no matter protected or
non-protected) is running under pKVM, but in fact it returns true for
protected VMs only, causing confusion (see [1]).
is_pkvm() is only used for checking if readonly memslots are supported.
Since this check is not really working correctly, Android is relying on
the out-of-tree crosvm patch [2] instead.
So just remove is_pkvm() and remove this check for the readonly memslot
capability. Note that although pKVM supports readonly slots for
non-protected VMs since android15-6.1 kernel [3] so we could replace
this is_pkvm() check with an explicit check for a protected VM
(KvmCap::ArmProtectedVm), that would be not enough since Android needs
to support older kernels, so it would still require the patch [2].
[1] https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5171308/comment/1c5fdc88_5b98a13f/
[2] https://android-review.googlesource.com/c/platform/external/crosvm/+/2880409
[3] https://android-review.googlesource.com/c/kernel/common/+/2984845
BUG=b:316956218
Change-Id: I7d3f0660c9de68fd7b32deebcc8a1c9707294ea2
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/6480181
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Dmytro Maluka <dmaluka@chromium.org>
Reviewed-by: Frederick Mayle <fmayle@google.com>
Starting with android16-6.12 kernels pkvm adds support for protected
guest VMs to FF-A protocol to communicate with trustzone.
Corresponding kernel UAPI is added in the following commit in ACK repo:
778832cb8b86ef8dbe66498ebb0c60f89629ccb2:
ANDROID: KVM: arm64: Introduce KVM_CAP_ARM_PROTECTED_VM_FLAGS_SET_FFA uapi
BUG=b:391774181
TEST=tools/presubmit
Change-Id: Ib48ce4d8a832e52fb9c0392c360a114a1c273c61
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/6381774
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Auto-Submit: Nikita Ioffe <ioffe@google.com>
Commit-Queue: Nikita Ioffe <ioffe@google.com>
It isn't correct that the static swiotlb is "outside of guest physical
memory".
Change-Id: Ie10acf0745c8dec0fb15430d89fbd368626732fe
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/6456665
Auto-Submit: Frederick Mayle <fmayle@google.com>
Commit-Queue: Frederick Mayle <fmayle@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
`--lock-guest-memory` uses `mlock` on the guest memory and then
`MADV_REMOVE` to free ranges, but `MADV_REMOVE` cannot be used on locked
memory ranges, so it requires sandboxing to be enabled and only performs
the `MADV_REMOVE` calls from the sandboxed balloon process (memory locks
are implicitly release on fork).
The new `--lock-guest-memory-dontneed` added in this commit uses
`MADV_DONTNEED_LOCKED`, which essentially does the same thing as
`MADV_REMOVE`, but it works correctly on locked ranges and so doesn't
require sandboxing. The downside is that it requires a 5.18 or newer
kernel.
BUG=b:407786138
Change-Id: Ib8e24d647a97b98abf5b3ba6b0356c9d9999a378
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/6451457
Commit-Queue: Frederick Mayle <fmayle@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
User code should only query IrqChipCap::TscDeadlineTimer; the VmCap
version of this was really an internal implementation detail of the KVM
irqchips, and exposing it in the public API would allow unintentionally
using the wrong one.
Additionally, this cleans up the unnecessary VmCap handling from non-KVM
hypervisors.
Change-Id: I9ee838e4c33015adc04e0f9fea2a28c118cb39f2
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/6448635
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Elie Kheirallah <khei@google.com>
Move capabilities to VM caps.
Move Arm only capabilities to be Arm only.
Delete unused cap.
BUG=N/A
TEST=presubmit
Change-Id: I13dfc190fd34ab22cacdcb1751b3f4861d70a4f7
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/6439654
Commit-Queue: Elie Kheirallah <khei@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Use the VM ioctl to check VM capabilities instead of the KVM ioctl.
Change it to x86 only as it is not used in other architectures.
Also add x86 config to x86 specific caps.
BUG=N/A
TEST=presubmit
Change-Id: Ibaea5aa959839d336e771f0f81a2909774d54ea6
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/6439653
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Elie Kheirallah <khei@google.com>
There a list of registers that do not follow the same pattern as other system
registers and are skipped from the list despite them being system registers.
System registers follow the pattern where bits 31-16 == 0x0013, but some
system registers in KVM do not follow that pattern, mainly being SPSR_*,
SP_EL1, ELR_EL1, FPSR and FPCR.
BUG=b:401304225
TEST=presubmit
Change-Id: Ia3a29ebd27a9a8493cb968db8cca66ee6486f54e
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/6391157
Commit-Queue: Elie Kheirallah <khei@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Frederick Mayle <fmayle@google.com>
Resolving feedback from https://crrev.com/c/6369873
* Failing to find the payload region should be an error
* Use iter find to shorten the code
* Avoid is_some -> unwrap anti pattern
BUG=b:399219478
Change-Id: I9f91ed7dfbdb04843276b84395fa2c66b279048f
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/6377058
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Frederick Mayle <fmayle@google.com>
Qualcomm Trusted VM (QTVM) is a kind of protected VM which differentiates
itself from from the traditional protected VMs that have been supported by
crosvm in a few aspects like -
1. identified by reserved VM ID and PAS ID pair.
2. authenticated by the firmware/TZ and not pvmfw.
3. A QTVM Image is single loadable elf Image which contains kernel, dtb, initrd and the metadata
needed for its authentication.
4. A QTVM can be backed by Contiguous Memory. Either the entire GuestMemory region could be
contiguous or it could be a combination of both CMA and shm.
As the guest memory now can contain regions backed by CMA, make the necessary IOCTLs to map these
regions to the VM. Also, add a new IOCTL to set the authentication type to be
GUNYAH_QCOM_TRUSTED_VM_TYPE.
Bug: 399219478
Change-Id: I2e8a8f64db18602769421b667e69ca3a77c29426
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/6369873
Commit-Queue: Frederick Mayle <fmayle@google.com>
Auto-Submit: Frederick Mayle <fmayle@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
An Android-specific ioctl was added to support reclaiming memory from
the guest. Wire it up so that when balloon inflates, crosvm attempts to
reclaim/free the memory.
Bug: 395833312
Change-Id: I72769fabd003ba00c1848a456400d7c8ed2a8d97
Signed-off-by: Elliot Berman <elliot.berman@oss.qualcomm.com>
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/6369872
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Frederick Mayle <fmayle@google.com>
Auto-Submit: Frederick Mayle <fmayle@google.com>
These were stabilized in Rust 1.80, so we can drop the external crate
and use the standard library implementation now that we have Rust 1.81.
Change-Id: I31daf78c67f7454f6e260b83fc386f955102d08c
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5321451
Reviewed-by: Frederick Mayle <fmayle@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
A new `aarch64_sys_reg` crate is created since this is not really
hypervisor specific (it is also used in `devices` for irqchip).
The bulk of the constants were generated with automated scripts of
varying levels of hackiness from the official XML descriptions:
<https://developer.arm.com/Architectures/A-Profile%20Architecture>
BUG=b:359958235
Change-Id: I74fa4f0cb6f99509fa0f4d5e4d8de969a3f2cf6c
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/6354986
Reviewed-by: Frederick Mayle <fmayle@google.com>
Reviewed-by: Elie Kheirallah <khei@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
- Re-enables riscv64 in tools/presubmit
- Re-builds the dev container with riscv64 dependencies
- Fixes a few clippy issues that have come up
- Re-enables the riscv64 builder in postsubmit
BUG=b:304875018
TEST=presubmit linux_riscv64 --no-delta
Change-Id: Icc67f924e2a3475f8f2aa1a5261dfc457afb66a1
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/6363077
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
This API can be used to retrieve the unique identifier of a VM.
Bug: b:360102915
TEST=tools/presubmit
Change-Id: Ic1e5f350c93bed68c7d9022af1eeaa0e773a7418
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/6324569
Auto-Submit: Nikita Ioffe <ioffe@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Nikita Ioffe <ioffe@google.com>
Reviewed-by: Frederick Mayle <fmayle@google.com>
The Gunyah Resource Manager previously assumed the PC as the starting
address for the VM memory parcel, which is incorrect with demand paging
because payloads may start at non-zero offsets and the Resource Manager
cannot determine the correct start address. To support non-zero offsets,
a new GUNYAH_VM_SET_BOOT_CONTEXT ioctl has been added, allowing userspace
to set the register state (boot context) of the guest before starting the VM.
Bug: 376917595
Change-Id: Ie07dbebdbf3bbbdf40c78987c92343867eac887a
Signed-off-by: Mukesh Pilaniya <quic_mpilaniy@quicinc.com>
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/6268024
Auto-Submit: Frederick Mayle <fmayle@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Replace open-coded reimplementations of these rounding-related math
functions where applicable (mostly identified as candidates for
div_ceil() by Rust 1.84 clippy, but in some cases, next_multiple_of()
was a better match).
Change-Id: Ib851689836cb8d44cde5a5766a3cec8fd5c90f40
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/6195237
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Frederick Mayle <fmayle@google.com>
Construct a separate guest memory region for each of the traditional PC
memory layout low-memory areas:
- 0 to 640 KB (RAM)
- 640 KB to 1 MB (reserved for memory-mapped devices, BIOS, and ROMs)
- 1 MB+ (RAM up to the 4 GB PCI hole)
This simplifies the e820 memory map generation code (it just copies the
exact layout from guest_mem.regions() and translates the memory type
values) and ensures the layout provided to the guest matches the actual
GuestMemory region layout.
The memory_layout documentation is also updated to reflect the layout
more accurately; the kernel and initrd regions are contained inside the
above-1MB RAM region, not separate regions on their own.
BUG=b:375568070
Change-Id: I1f35694365a0ec9966b4d208190db103b48e9045
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/6086957
Reviewed-by: Frederick Mayle <fmayle@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
The initial code for enabling SVE via the auto flag would check if SVE
is supported on the hypervisor. The result was the KVM ioctl advertising
the SVE capability, but a VM could be built without SVE support, which
would cause the VM ioctl to not advertise the SVE option, resulting in
failure of creation of the VM.
KVM API documentation suggests using the VM ioctl to adapt specifically
to the VM created. This patch replaces the KVM ioctl with the VM ioctl
call.
BUG=b:376260018
TEST=AOSP
Change-Id: I5062ee188131b3863a5b64c68c0348e471747476
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/6215250
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Auto-Submit: Elie Kheirallah <khei@google.com>
Commit-Queue: Elie Kheirallah <khei@google.com>
The heavy use of `serde_json::Value` in the snapshot APIs makes it
difficult to experiment with other serialization frameworks. The vast
majority of the code just needs to supply a type that is serde
compatible and doesn't need to know what the format is.
On an aarch64 `--profile chromeos` build, the binary size barely changed
(it actually went down very slightly, -10kb, maybe because of the
equality comparisons I deleted), so I don't expect it to introduce any
overhead. The output files look the same.
Change-Id: Ie41d1bf6f6e3197566110774cfb5f20d00d85682
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/6161187
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Frederick Mayle <fmayle@google.com>
Reviewed-by: Elie Kheirallah <khei@google.com>
Reviewed-by: Noah Gold <nkgold@google.com>
Add auto to Sve config that checks if the system supports SVE and
enables it accordingly.
BUG=b:376260018
TEST=presubmit
Change-Id: I032d2d6b214f631839e0e8cc4812887771d307ac
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/6180906
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Elie Kheirallah <khei@google.com>
