Add the minimal allow(dead_code) and feature declarations to allow the
clippy checks to pass for Windows with Rust 1.81.
BUG=b:365852007
TEST=tools/presubmit clippy_mingw64
Change-Id: I9ab776b07d8e9e14fe380d9b5ef1fa332788ff63
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/6013080
Reviewed-by: Kaiyi Li <kaiyili@google.com>
Reviewed-by: Noah Gold <nkgold@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Refactor `init` and add function `get_features` to get the Vcpu features.
Previously some features were only retrieved as part of `init`.
Add function `finalize` which is required for SVE support. SVE requires
`KVM_ARM_VCPU_INIT` to be called first, which gives access to the SVE
config, specifically `KVM_REG_ARM64_SVE_VLS`, which is a
pseudo-register that allows discovering and configuring the vector
lengths by userspace. After `finalize` is called,
`KVM_REG_ARM64_SVE_VLS` is no longer accessible, and the config is
final. In this patch, we are not modifying the vector lengths, reason
behind this is `KVM_ARM_VCPU_INIT` initializes `KVM_REG_ARM64_SVE_VLS`
to the best set of vector lengths that the host supports.
BUG=b:375372656
TEST=presubmit
Change-Id: Ibd0902ad68f28b9d4e9a595070fe972e620e5572
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5973935
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Frederick Mayle <fmayle@google.com>
Commit-Queue: Elie Kheirallah <khei@google.com>
Previously, the Vcpu handle_io() and handle_mmio() functions used an
IoOperation containing a fixed-length data array to represent a write
and returning a fixed-length data array to represent a read, along with
a separate size field to indicate how much of the fixed-length array
should be read/written.
This change uses Rust slices to represent the I/O data instead:
- Write contains a &[u8] of data to be written.
- Read contains a &mut [u8] to be filled with the read data.
The new IoOperation matches the Bus read()/write() APIs more closely,
and avoids the need for hypervisors and callers to convert between
fixed-size arrays and slices.
The Bus::read() function now always initializes the data slice before
(potentially) calling a device's read() function. This ensures
consistent results even if a device does not always fill out every data
byte (for example, the default BusDevice read() handler that is a no-op)
or if no device is found. This replaces the previous zeroing that would
happen when initializing the read data array to return from handle_fn.
Without this, the data slice may have had stale data from the previous
MMIO/IO exit, depending on the hypervisor implementation.
No functional change intended.
BUG=b:359382839
TEST=tools/dev_container tools/presubmit
Change-Id: Id88ebfa7ece5cc7466c010db2cbde303aeb97bf8
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5913962
Reviewed-by: Vaibhav Nagarnaik <vnagarnaik@google.com>
Reviewed-by: Noah Gold <nkgold@google.com>
Reviewed-by: Frederick Mayle <fmayle@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
This tests repeated I/O string instructions call the handle_io callback
the correct number of times with the expected size.
BUG=b:283990685
Change-Id: Ia8b55c7059082376d6cdd825224f362f46bd0ea2
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5798664
Reviewed-by: Oystein Eftevaag <oysteine@chromium.org>
Reviewed-by: Noah Gold <nkgold@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Judson Powers <judsonp@google.com>
For repeated string port I/O instructions (REP OUTSB, REP INSB, and
similar for other data sizes), the size field specifies the size of one
operation, and count specifies the number of times to repeatedly
read/write the *same* port with *different* data. This was fixed for KVM
in commit 063708084c ("hypervisor: kvm: handle INS/OUTS VM exits");
apply the same fix to HAXM.
BUG=b:283990685
Change-Id: Iaf4cfe12fba816730030368651db0e6fb116e50a
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5798663
Reviewed-by: Noah Gold <nkgold@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Judson Powers <judsonp@google.com>
When shared refs are used, the compiler may generate code that doesn't
witness the new value written via the pointer.
Change-Id: I6354fc3af749eaf7aaf1369c30b273371047d351
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5893919
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Frederick Mayle <fmayle@google.com>
This doesn't build upstream, but cfg(feature = "gvm") is checked in
various places in upstream code, which becomes a warning in Rust 1.80.
BUG=b:365852007
Change-Id: Ib13f8b6ce965f790b292db1cf827472a292473da
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5894665
Reviewed-by: Noah Gold <nkgold@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
This was added in the original hypervisor abstraction layer since it was
in the kvm crate, but it isn't actually used anywhere in crosvm.
BUG=None
TEST=tools/dev_container tools/presubmit
Change-Id: Ie1eacbe90771b050e3a60a0c868362d2d454d99e
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5660939
Reviewed-by: Richard Zhang <rizhang@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
For GZVM_CAP_PROTECTED_VM at least, the GZVM_CHECK_EXTENSION ioctl
ovewrites its parameter with the result rather than using the return
value, so its parameter needs to be a mutable reference.
Change-Id: Ief9f153804ebb57e2b247f2b6a5f04b429c77a7d
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5847469
Reviewed-by: Frederick Mayle <fmayle@google.com>
Commit-Queue: Frederick Mayle <fmayle@google.com>
These tests currently don't pass on KVM (at least on AMD), and I don't
think the tests are actually testing for the expected result (there is
no configured IDT, so the system triple faults and ends up at the reset
vector), which seems nontrivial to fix, so skip them on Linux for now.
This makes `tools/dev_container tools/presubmit` pass for me again.
Change-Id: Ifc31fdd88b270c1c37f0f105dc655be4048ed279
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5888352
Reviewed-by: Oystein Eftevaag <oysteine@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Frederick Mayle <fmayle@google.com>
As pKVM and pvmfw development for x86 is ongoing, add initial support
for running VMs with pvmfw as the VM bootloader. For now only support
the --unprotected-vm-with-firmware development flag, for running regular
non-protected VMs with pvmfw, which doesn't require pKVM support.
Similarly to ARM, add a dedicated memory region for pvmfw to the x86-64
memory map. This region is located right below the PCI MMIO memory hole.
Its size is 4MB, like on ARM.
Similarly to ARM, the pvmfw entry point is at the beginning of the pvmfw
image, the normal x86-64 boot protocol is kept as is, and additionally
the VM payload (i.e. kernel) entry point is passed to pvmfw in the %rdi
register. This ABI is a subject to change, the final ABI for x86 pvmfw
is not defined yet.
BUG=b:354676864
TEST=1. Run a VM with "--unprotected-vm-with-firmware pvmfw_test.bin"
where pvmfw_test.bin begins with the "jmp *%rdi" instruction (2 bytes:
0xff 0xe7), i.e. pvmfw immediately jumping to the VM entry point.
Result: VM runs as usual.
2. Run a VM with "--unprotected-vm-with-firmware pvmfw_random.bin" where
pvmfw_random.bin contains just random data. Result: VM crashes.
Change-Id: Ib0ee998a99a0cf352a97222769b87be615419187
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5797353
Commit-Queue: Dmytro Maluka <dmaluka@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Lazy-init of VirtioPciDevice shared memory region (to setup hypervisor
mapping) would previously use the MemCacheType seen on first mapping,
which could be anything -- this behavior is never desired, but grew from
a later addition of MemCacheType workaround to the existing Virtio "Fixed
Mapping" optimization.
On devices where the single hypervisor mapping's MemCacheType matters
(e.g. for devices that must configure it with
MemCacheType::CacheNonCoherent), if the first mapping attempted is for a
shmem with WB caching, all later mappings with WC or UC memtype would be
configured incorrectly.
Instead, query the VirtioDevice Trait implementator whether lazy-init of
a single hypervisor mapping should be used (the default), and with which
MemCacheType.
Attempting to later add a `CacheNonCoherent` mapping for a device that
explicitly declared `SingleMappingOnFirst(CacheCoherent)` is invalid,
and would lead to bugs, so we now treat this as an error and fail the
mapping altogether.
VirtioGpu device implementations will use this for devices with either
mandatory or optional-but-enabled non-coherent DMA (e.g. Intel devices
without coherent LLC shared between CPU/GPU, or that may opt to bypass
LLC coherency for optimal perf).
BUG=b:360295883, b:246334944
TEST=Builds
Change-Id: If41d238fd3c220e45c61d78da4a2505572709053
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5871721
Commit-Queue: Ryan Neph <ryanneph@google.com>
Reviewed-by: David Stevens <stevensd@chromium.org>
Some doc comments were being incorrectly interpreted due to missing
indentation (for intentional line contintuations) or line breaks (for
new lines that were intended to be separate paragraphs).
Clippy warns about these as of Rust 1.80:
<https://rust-lang.github.io/rust-clippy/master/index.html#/doc_lazy_continuation>
Fix them along with some other nearby minor formatting cleanups.
TEST=tools/cargo-doc
TEST=tools/clippy # with rust-toolchain 1.80
Change-Id: Ice0b7cc3bd75d9ab08c10107a13f95ca9f87a0a3
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5758934
Auto-Submit: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Frederick Mayle <fmayle@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
This allows the long mode tests to config task state segment and IST,
which further allows tests to switch the interrupt stack without having
to change the privilege level.
TEST=./tools/dev_container cargo nextest run --workspace --profile=default -E 'package(hypervisor) & binary(hypervisor_virtualization)' --retries 0 --no-capture
BUG=b:354901961
Change-Id: I9a118fb6eee1e7186b40f9e877583381acaa2aef
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5838082
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Kaiyi Li <kaiyili@google.com>
This change also changes the default long mode paging to make the first
2MiB use 4K pages, because 4K pages brings less memory pressures if the
test wants to configure different pages.
TEST=./tools/dev_container cargo nextest run --workspace --profile=default -E 'package(hypervisor) & binary(hypervisor_virtualization)' --retries 0 --no-capture
BUG=b:354901961
Change-Id: Ib03eb49e465018a154447534f07bdac0d8b74d2d
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5835891
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Kaiyi Li <kaiyili@google.com>
The KVM code that retrieves MSRs was using ioctl_with_ref(), which is
supposed to have a read-only reference, but KVM_GET_MSRS needs to write
via the provided reference.
Change-Id: I2f0972463c99d7d97f19834d23040ab49bbee20d
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5847468
Reviewed-by: Frederick Mayle <fmayle@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Elie Kheirallah <khei@google.com>
... which will allow to config GDT, IDT, and page tables in hypervisor
tests in following CLs.
TEST=./tools/dev_container cargo nextest run --workspace --profile=default -E 'package(hypervisor) & binary(hypervisor_virtualization)' --retries 0 --no-capture
BUG=b:354901961
Change-Id: Id0c2399fb28b915a244ddd9413b4086b98936280
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5836773
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Kaiyi Li <kaiyili@google.com>
Reviewed-by: Judson Powers <judsonp@google.com>
`KVM_CREATE_DEVICE` turns into an `ioctl` that mutates `device`, so
`device` must be declared as `mut`. Rust 1.78 forwards `device.fd == 0`
to the `Ok(...)` return, which made this incorrect code more visible.
BUG=b:361302729
TEST=Built & ran with Rust 1.78.
Change-Id: Idf99228b67c657351681adcaec563dd021fbe451
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5838113
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
* test_msr_access_invalid: Setting an invalid EFER bit gives a shutdown rather than a VcpuRun failure now
* test_getsec_instruction: Enter long mode first
* test_xsetbv_instruction: Long mode
* test_invept_instruction: Long mode
* test_invvpid_instruction: Long mode
Bug: 359608908, 342183625
Change-Id: Ife4e5dafc9894ce9f7ded84eae740183599d0ba7
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5787016
Reviewed-by: Judson Powers <judsonp@google.com>
Commit-Queue: Oystein Eftevaag <oysteine@chromium.org>
Reviewed-by: Noah Gold <nkgold@google.com>
Gives the method a better name as not only was it not clear but it was
confusing, potentially being interpreted as the hypervisor (implementing
the protection type) loading the firmware, similarly to how it performs
what .isolates_memory() refers to.
Note: No functional change intended.
TEST=-
Change-Id: Ie7d7fb9dc3732658837ce035298c374e6e52bf30
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5800574
Auto-Submit: Pierre-Clément Tosi <ptosi@google.com>
Commit-Queue: Pierre-Clément Tosi <ptosi@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Dmytro Maluka <dmaluka@chromium.org>
The winfo field is only populated with capability bits if wstatus is
nonzero. If wstatus is zero, those bits are re-used and indicate why
HAXM is not usable.
Bug: 357064526
Test: tested locally
Change-Id: I9cb0c82267095e4f89c879d48d8a3b7c00dfe36c
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5792562
Commit-Queue: Idan Raiter <idanr@google.com>
Commit-Queue: Judson Powers <judsonp@google.com>
Auto-Submit: Judson Powers <judsonp@google.com>
Reviewed-by: Idan Raiter <idanr@google.com>
Similar to WHPX, it looks like HAXM's segment_desc_t structure exactly
mirrors the Intel VMCS, where segment limits are always represented in
bytes.
From the Intel SDM Vol. 3, 25.4.1 ("Guest Register State"):
> Segment limit (32 bits). The limit field is always a measure in bytes.
Fixes: 2fc3047b9b ("hypervisor: x86_64: clarify Segment limit units")
Change-Id: I533216ea2359d1702d72cae0192e11e0478cf2c3
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5751215
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Oystein Eftevaag <oysteine@chromium.org>
Reviewed-by: Noah Gold <nkgold@google.com>
If our internal handling for MMIO fails catastrophically, we should
inject a GP fault (we can't satisfy the MMIO, and the guest needs to
know that).
BUG=b:352191269
TEST=builds (tested downstream)
Change-Id: I28919879e8451a3802c0ca353bc5abe2f2ed4199
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5777253
Reviewed-by: Idan Raiter <idanr@google.com>
Commit-Queue: Noah Gold <nkgold@google.com>
Reviewed-by: Vaibhav Nagarnaik <vnagarnaik@google.com>
It seems that WHPX also wants its segment Limit value to be in bytes
(unaffected by the Granularity flag), similar to KVM.
This also fixes a compilation failure (using "limit" rather than
"limit_bytes").
Tested with a 32-bit bzImage kernel on Windows 10 host.
Fixes: 2fc3047b9b ("hypervisor: x86_64: clarify Segment limit units")
Change-Id: Ifa013b3687a5febd4d36b3a830c9c6995cc2bdb9
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5743006
Reviewed-by: Noah Gold <nkgold@google.com>
Auto-Submit: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Noah Gold <nkgold@google.com>
The limit value in a kvm_segment is intended to be in bytes, meaning it
should already include the scale factor from the G (granularity) field.
This is basically undocumented, but this is based on observation of the
values assigned to kvm_segment limit fields inside the kernel being
larger than 20 bits.
Rename the field in the generic Segment struct to "limit_bytes" to make
its units clear and match the KVM behavior.
I could not find documentation for either WHPX or HAXM to determine
whether their limit fields should be in units of bytes or not, so those
hypervisors currently perform the conversion to maintain the previous
behavior of using the raw limit field as encoded in the GDT entry.
This mostly does not matter for 64-bit guests, since segment limit
fields are ignored in long mode, but it does matter in 32-bit protected
mode.
BUG=b:354053941
Change-Id: I1e464d3e1b8556184c732adea034b326e5ed6a72
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5727075
Reviewed-by: Noah Gold <nkgold@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Write an invalid MSR, check GP handler runs. Initially written in real
mode but we saw Intel HAXM doesn't work, so swapped to long mode. Better
to test what we really will be doing anyway.
BUG=b:334055761
TEST=run test
Change-Id: If97b720d13eb796fd8d3b45dd4fcef25d0abf59c
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5714993
Reviewed-by: Noah Gold <nkgold@google.com>
Commit-Queue: Idan Raiter <idanr@google.com>
Reviewed-by: Oystein Eftevaag <oysteine@chromium.org>
Cache architecture information is written per cache level. Cache levels
are selected by writing to the register CSSELR_EL1. To perform a
complete snapshot, save all the cache information and restore it.
The code at the end writes back the previously existing CSSELR_EL1
value, to avoid changing behavior in the system.
BUG=b:274145255
TEST=presubmit, AOSP
Change-Id: Ie9fdef1f3aa6f5633f832ea136d389c129c1868d
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5689416
Reviewed-by: Pierre-Clément Tosi <ptosi@google.com>
Commit-Queue: Elie Kheirallah <khei@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
We need to verify that a hypervisor is flushing a TLB on region
removal. This test removes a region in the middle of the VM running,
which allows us to verify that MMIO occurs on the next instruction,
rather than a read from an unmapped region.
BUG=b:333728516
TEST=presubmit
Change-Id: I215520ecfd4181a1e1ebd3cb5d784b3db94e799a
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5690379
Reviewed-by: Idan Raiter <idanr@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Noah Gold <nkgold@google.com>
Add get_system_regs function to AArch64.
This function should return all advertised system registers by the
hypervisor.
BUG=b:274145255
TEST=AOSP on ARM64
Change-Id: Ia472863d70e1cf29fb745fa4afd6a11dc0d44b78
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5445727
Commit-Queue: Elie Kheirallah <khei@google.com>
Reviewed-by: Pierre-Clément Tosi <ptosi@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Retrieve the kvmclock capability once in KvmVm::new() instead of
checking it in each call to create_kvm_vcpu().
BUG=None
TEST=tools/dev_container tools/presubmit
Change-Id: I4acf3fbd68999a7b4aa517553b6684f27629e0e9
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5671241
Reviewed-by: Frederick Mayle <fmayle@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Create a Path directly in Kvm::new() rather than constructing a PathBuf
and borrowing it.
BUG=None
TEST=tools/dev_container tools/presubmit
Change-Id: Icf46c48dc2dde3548cc796fc0162d5b57d4ad9bd
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5671064
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Frederick Mayle <fmayle@google.com>
We don't need to call ioctl(KVM_GET_VCPU_MMAP_SIZE) repeatedly for each
vcpu; the result is constant. Retrieve it once during Kvm::new().
BUG=None
TEST=tools/dev_container tools/presubmit
Change-Id: Ibe9607524198cc65c00f1ac0be1311934d7a9671
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5671063
Reviewed-by: Frederick Mayle <fmayle@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
KVM was excluded from several tests; these mostly did not work because
the test setup code failed to configure CPUID, so the guest vCPUs did
not have any CPUID bits enabled.
BUG=None
TEST=cargo test -p hypervisor
Change-Id: I8c42c90a3547c011ab4f62fa94b31d05b0af6d15
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5677667
Reviewed-by: Kaiyi Li <kaiyili@google.com>
Reviewed-by: Noah Gold <nkgold@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
There was a missing comma, so the global_asm macro failed to parse the
assembly. This test is conditionally enabled only for whpx, so it did
not cause the CI to fail since whpx is not enabled there currently.
BUG=None
TEST=cargo test -p hypervisor --features=whpx
Change-Id: I0f6788eacc46c12baeee9827202b68635cbe2e2a
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5677434
Reviewed-by: Noah Gold <nkgold@google.com>
Commit-Queue: Noah Gold <nkgold@google.com>
Auto-Submit: Daniel Verkamp <dverkamp@chromium.org>
This will let us use the MemoryMappingBuilder::from_file() function that
accepts &File directly rather than the generic from_descriptor() that
takes a &dyn AsRawDescriptor.
BUG=b:242953353
TEST=tools/dev_container tools/presubmit
Change-Id: I6866243d8959e5b5d48d05f6a04fac5c8ffe02cd
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5671359
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
... to always not to inject an interrupt in a not interruptible window.
Test: presubmit
Change-Id: I303de46b023df4ba0b33624f392d31103da7beec
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5664544
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Frederick Mayle <fmayle@google.com>
Commit-Queue: Kaiyi Li <kaiyili@google.com>
The caller of VcpuX86_64 should normally check ready_for_interrupt()
before calling interrupt(), but it is relatively cheap to add the check
to interrupt() itself and return an error in the case of incorrect use.
For KVM on x86, this is only called in the split irqchip mode, so it
should not affect performance in the normal in-kernel irqchip crosvm
configuration. In any case, the data accessed by ready_for_interrupt()
should be cheap to access since it will already be in the cache on the
second call.
Fixes hypervisor::test_interrupt_injection_when_not_ready on Linux/AMD.
BUG=None
TEST=tools/dev_container tools/presubmit
Change-Id: Id830771b3fc920d1e9705275f1da3efdd3de3367
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5651809
Reviewed-by: Kaiyi Li <kaiyili@google.com>
Reviewed-by: Frederick Mayle <fmayle@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
offset_of!() is available in the standard library as of Rust 1.77.
Also update intrusive-collections 0.9.4 -> 0.9.6, which drops an
indirect dependency on memoffset 0.5.6:
cargo update -p intrusive-collections
BUG=b:344974550
TEST=tools/dev_container tools/presubmit
Change-Id: I37a9bf0aee5f5f55bdea1e17d71889e8a3badb36
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5667936
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
