We don't actually need the guest frame number in the VmMemoryRegionId
(it is just an opaque value that needs to be unique for each region),
and the frame number calculation depends on the page size, so it's
simpler to just use the guest physical address itself without shifting
it.
Change-Id: I75d181c7e07f79b5e0ba0bf0a1174d4f71263bb8
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/6027193
Reviewed-by: Elie Kheirallah <khei@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
This makes the offset math simpler, since both sides are in units of
bytes instead of pages.
Change-Id: I677228b25ef25003d4f19c1c8c67beec236fb8d4
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/6027192
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Elie Kheirallah <khei@google.com>
It was unused aside from the Display impl, which is only used for debug
prints.
Change-Id: Ie87a44e53e512b57032d5862ffb180ed57aaa0ba
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/6027191
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Elie Kheirallah <khei@google.com>
The performance range of pCPU that the vCPU is running on is limited by
the frequency range that it supports. There are some usecases where even
running the pCPU at its lowest frequency will still be too fast to
accurately emulate a much smaller vCPU.
Add a worker to throttle the vCPU by adding a fixed amount of work to
the vCPU at varying intervals depending on the vCPU's requested
performance.
The relationship to determine the interval is:
THROTTLE_PERIOD = THROTTLE_TIME / (1.0 - VCPU_PERF / PCPU_PERF);
The worker will only throttle vCPU when it requests a performance point
below the performance of pCPU@Fmin, but otherwise falls back to using
frequency ratios to emulate smaller vCPUs.
By emulating correct vCPU sizes and topologies, this enables Cuttlefish
to accurately model real life SoCs and kernel scheduler behaviors inside
the guest. This allows for better power and performance related testing
at scale using ARM64 servers.
Bug=b:284367589
Test: tools/presubmit
Change-Id: Ide6f61a68ea59cee0db163829839ad575db1b208
Signed-off-by: David Dai <davidai@google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5980807
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
This CL adds two crosvm_control APIs for faking power and resuming
power from fake configuratiion. The APIs are designed for support arcvm
doze mode.
The crosvm_client_fake_power() is used to set battery's fake
configuration. The power status will always be on battery, which means
ac_online=0. Also, the maximum battery capacity that could be read by
guest is set to max_battery_capacity.
The crosvm_client_cancel_fake_power() is used to resume battery from
fake configuration. The battery device will report real host power
status.
BUG=b:353609634
TEST=write C program to call api & test manually
Change-Id: I30513847cfacc211bce885d2ff794fc7ae535c7c
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5715936
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Yuan Yao <yuanyaogoog@chromium.org>
Add a vm_control::MmapAndRegisterMemory request to ask the main process
to do mmap() for given FDs to the given shm and register the region to
the guest.
This request will be used by pmem-ext2 device in the next CL.
BUG=b:329359333
TEST=presubmit
Change-Id: I365fc582f832401ada0556b28beda078d687a53f
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5872163
Reviewed-by: Takaya Saeki <takayas@chromium.org>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Previously, RTC wake would cause a synchronous run state change and also
asynchronously trigger wakeup through suspend_pipe. The first one is
redundant, so remove it.
BUG=b:345278018
TEST=rtcwake -m standby --seconds 10 wakes up Ubuntu VM.
Change-Id: I8ce78e3f286052bd683adfaa233eebfaa4824b86
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5834902
Commit-Queue: Tatsuyuki Ishi <ishitatsuyuki@google.com>
Reviewed-by: David Stevens <stevensd@chromium.org>
There were two ways to handle a VM request that involves run state
change:
1. By executing it immediately through kick_vcpus.
2. By returning the desired state which will be then transitioned to by
the caller.
Using #1 has the advantage that operations that needs to be done *after*
the run state change can be described in the function that performs the
run state change. In particular, pvclock's suspend callback needs to be
invoked after the VCPUs are stopped, but currently it happens *before*,
leading to b/345278018 (negative time overflow on ARM64 with pvclock).
This change converts all run state changes to #1 except for exits
(which can't be done by kick_vcpus).
The resume_imminent handling, previously handled by
linux::process_vm_control_event, is moved into kick_vcpus to preserve
behavior. Note that resume_imminent is currently called even if the
suspension is initiated by the host, but we keep bug-to-bug
compatibility for now and leave this to be fixed later.
Suspend responses for force_s2idle is now omitted by returning None
from process_vm_request. This avoids plumbing suspend_requested further
down the chain.
BUG=b:345278018
TEST=None (see next CL)
Change-Id: I2f63c3888715a5b612d1201481ce29677b94e884
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5823029
Reviewed-by: Noah Gold <nkgold@google.com>
Reviewed-by: David Stevens <stevensd@chromium.org>
Commit-Queue: Tatsuyuki Ishi <ishitatsuyuki@google.com>
Vmwdt is getting the pid/tid of vCPUs whenever a write happens. Instead,
get the Vcpu PID/TID on VM startup.
BUG=b:274145255
TEST=presubmit
Change-Id: I4f41dd20b807b320b6202d36061b18d4c9aa77df
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5703919
Commit-Queue: Elie Kheirallah <khei@google.com>
Reviewed-by: Frederick Mayle <fmayle@google.com>
Auto-Submit: Elie Kheirallah <khei@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
The kvmclock keeps ticking even when vcpus are stopped, so right now the
guest perceives a big clock jump (10-20s for 8GB CF on a workstation)
that matches the time taken to perform the expensive parts of the
restore, like copying the RAM. As an improvement, move the clock restore
as close as possible to the vCPU start/stop. Even with this, there is
still a 3-4 second jump, but I don't yet know where it is coming from.
Note that only x86 KVM advertises `VmCap::PvClock`. This is a noop for
all else.
BUG=b:340216366
Change-Id: Ib4d870db5b31adb9c82076018035a842052d7cb8
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5617778
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Noah Gold <nkgold@google.com>
Commit-Queue: Frederick Mayle <fmayle@google.com>
This change enables clippy builds of android specific code.
Doing so without adding the full Android SDK into our container
is a bit hacky. The CL https://crrev.com/c/5671653 adds env variables
to the minijail build.rs to allow us to skip building the library, and
generate bindings for linux instead of android.
This allow us to build all non-gpu related features of the
android build. It will not link, but it will run clippy.
This CL fixes various clippy issues that come up in this new
configuration
BUG=b:349907813
TEST=tools/clippy -p android
TEST=tools/presubmit clippy_android
Change-Id: I1f51d383051bbeeeff55d716feb7b56c3e24588b
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5672567
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
A comment describing state in get_vcpu_state was chopped off and merged.
Completed the comment.
BUG=N/A
TEST=presubmit
Change-Id: I1e635fb2b90232869632f1349c46d5a5012190a0
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5683683
Commit-Queue: Elie Kheirallah <khei@google.com>
Auto-Submit: Elie Kheirallah <khei@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Previously these were tracked by MemSlot (hypervisor id assigned to a
dynamically mapped hostVA), since every dmabuf had its own.
With the recent support for "fixed" virtgpu blob resource mapping
(contrasting the earlier per-blob "dynamic" mapping), every mapped
dmabuf now shares a single MemSlot, which is configured at VM boot for
the entire device BAR.
Obviously, to support "fixed" blob mapping + virtio-iommu dmabuf
mapping, the latter needs to be tracked at the mapped dmabuf
granularity, not the hypervisor memslot granularity. We already have a
VmMemoryRegionId, which is a unique u64 derived from the guest physical
address for a blob resource to serve this purpose.
BUG=b:323368701
TEST=tools/dev_container tools/presubmit
Change-Id: I2340db38df3a4a885031521ded66a82ef78236e6
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5542922
Reviewed-by: David Stevens <stevensd@chromium.org>
Commit-Queue: Ryan Neph <ryanneph@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Refactor and rename tracking structures for guest physical memory
mappings (hypervisor user memory regions) and registered memory (either
a dynamic memory region mapping or a sub-mapping of existing fixed user
memory region).
BUG=b:323368701
TEST=tools/dev_container tools/presubmit
Change-Id: I328aba53c5e6cc4e1dbdfe000c7e75931dfe3969
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5542921
Commit-Queue: Ryan Neph <ryanneph@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Just use the gpa directly, instead of masking to gfn then back.
Retain the same guarantees as with gfn-based tracking by validating
page-alignment at registration-time. Except this is validated against
the virtio-iommu devices _actual_ pagesize, rather than an assumed one
placed elsewhere in the source.
Also adds validation of the requested mapping range.
BUG=b:323368701
TEST=tools/dev_container tools/presubmit
Change-Id: Ib0f52ae18d06f8d2489f2229488dc6fc1932dba4
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5542920
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Ryan Neph <ryanneph@google.com>
Reviewed-by: David Stevens <stevensd@chromium.org>
Disambiguate this "offset" from others in the same procedure.
BUG=b:323368701
TEST=tools/dev_container tools/presubmit
Change-Id: I363e93cd0ddfc3c69f840c2ac7852f830b833ca7
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5542919
Reviewed-by: Takaya Saeki <takayas@chromium.org>
Reviewed-by: David Stevens <stevensd@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Ryan Neph <ryanneph@google.com>
More clearly distinguishes between ::FixedMapping and ::DynamicMapping
and their associated tracking data.
BUG=b:323368701
TEST=tools/dev_container tools/presubmit
Change-Id: Ie6079a8d6a77b136fc2c3011e88a0764e9c5cce0
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5541247
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: David Stevens <stevensd@chromium.org>
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
Commit-Queue: Ryan Neph <ryanneph@google.com>
Import balloon_control items directly from that crate rather than via
re-exports from vm_control.
This fixes the fuzzer build, which depended on an implicitly imported
type via one of the conditional wildcard imports.
BUG=chromium:69590
TEST=(cd fuzz; cargo build)
Change-Id: I97d5df66741cfb64f600bebd503b73d779888440
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5630345
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
The crosvm_control library's API and ABI should not depend on crosvm
configuration options. If functionality is not available in a particular
build, the library should just provide a stub version of the function
that returns an error, rather than changing the exported symbols or
function prototypes.
BUG=None
TEST=tools/dev_container tools/presubmit
TEST=cargo build --no-default-features -p crosvm_control
Change-Id: I4428d3efe8d52a16ec78998fd83cd7d16b6b7773
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5623295
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Frederick Mayle <fmayle@google.com>
The vm_control client depends on crate imports that were implicitly
getting pulled in by a wildcard pub re-export. Remove the wildcard
import and import only the required types.
BUG=b:344974550
TEST=cargo build -p vm_control
TEST=cargo build -p vm_control --features=gpu
TEST=tools/clippy
Fixes: df8168ad25 ("Remove unused pub re-exports")
Change-Id: I83461203482d0174b8ca85c1cb1aadeb9afd2097
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5623434
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Virtio-snd on Windows will take a audio_client_guid on initialization.
A device index is also added so that logs can be differentiated between
multiple audio devices
TEST=ran emulator downstream
BUG=b:342181161
Change-Id: Ia156b3ad2a9cc447a7e350a1915762f23e25f9cb
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5563959
Commit-Queue: Richard Zhang <rizhang@google.com>
Reviewed-by: Noah Gold <nkgold@google.com>
Reviewed-by: Chih-Yang Hsia <paulhsia@chromium.org>
Ensure that every Cargo.toml dependency on a third-party crates.io crate
specifies at least a major version, or a minor version for 0.x crates,
to ensure that if a new major version is published, it cannot cause API
breaks.
The versions are selected to match the ones already in Cargo.lock, so
this should have no functional change, but it will help prevent new "*"
versions from being introduced via copy-and-paste.
For rationale, see the Cargo FAQ:
<https://doc.rust-lang.org/cargo/faq.html#can-libraries-use--as-a-version-for-their-dependencies>
`minijail`, `audio_streams`, and `cras` are left as "*" for now, since
they have unusual situations (imported from a submodule and/or replaced
at build time with ebuild magic).
BUG=None
TEST=tools/dev_container tools/presubmit
TEST=verify Cargo.lock is unchanged
Change-Id: Ifa18199f812f01d2d10bfb4146b3353c1a76527c
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5555656
Reviewed-by: Frederick Mayle <fmayle@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Design doc: go/arcvm-virtual-swap-impl
BUG=b:329310285
TEST=./tools/dev_container ./tools/presubmit
TEST=crosvm run with virtual swap options, set up the pmem device as an
swap area, verify the swapped in memory from guest are released from the
host swap.
TEST=crosvm run --pmem file.img, verify file size is 0 with
blkdiscard(8) from the guest that discards the whole file
Change-Id: Ie8f2910886ea754b9490fe5e762b578ca9d20a24
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5531228
Reviewed-by: Takaya Saeki <takayas@chromium.org>
Commit-Queue: Hung Nguyen <hungmn@google.com>
The new options will allow a virtio-pmem to be created based on an
anonymous memory mapping, and can be paged out at the specified
interval. The created virtio-pmem device can be used as a swap area in
the guest, where the guest swapped out memory will be paged out to the
host swap area.
Design doc: go/arcvm-virtual-swap-impl
BUG=b:329310285
TEST=./tools/dev_container ./tools/presubmit
TEST=tested seccomp policy with armv7-unknown-linux-gnueabihf and
aarch64-unknown-linux-gnu targets running on 32 bit (hana) and 64 bit
(kukui) ARM devices
TEST=crosvm run with new pmem options
Change-Id: Icd261bf94ba9c8168b9274b8e56fe352f153b9e6
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5529961
Reviewed-by: Takaya Saeki <takayas@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Hung Nguyen <hungmn@google.com>
When kvm clock is available, Linux (6.1 at least) uses it for the
scheduling clock (among other things) even when the TSC is configured as
the primary clock source. When restoring a VM, if we don't make a
KVM_SET_CLOCK call, kvm clock's value will rollback to zero and cause
trouble.
`ClockState::flags` was deleted because it had no existing uses, it
isn't useable in any hypervisor generic way, and because it will result
in incorrect behavior for snapshotting. The set of valid flags returned
by KVM_GET_CLOCK is not the same as the set of valid flags that can be
passed to KVM_SET_CLOCK.
Bug: 339527192
Change-Id: I57503e72499a44e98e0c6ca93eb8cb01cb21c16d
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5530677
Reviewed-by: Elie Kheirallah <khei@google.com>
Commit-Queue: Frederick Mayle <fmayle@google.com>
We decided long ago to only support restoring a snapshot to a new VM,
using `crosvm run --restore`, this command is just a vestige.
Change-Id: I14bb20e3b89c41b277b11fe672d3ce21322cf656
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5530862
Reviewed-by: Noah Gold <nkgold@google.com>
Reviewed-by: Elie Kheirallah <khei@google.com>
Commit-Queue: Frederick Mayle <fmayle@google.com>
Allow the RTC to re-assert the SCI when it is resampled, to
make sure that wakeup events which occur during suspend actually wake up
the guest. Similar to GPEs, cmos passes an Event that will be
signaled when the RTC is cleared.
BUG=b:301862490
TEST=Manual test with ArcS2Idle feature flag
TEST=manual tests with rtcwake
Change-Id: Ife667e46e6a89ea9dcb868696493f401758988a7
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5512664
Commit-Queue: David Stevens <stevensd@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Allow virtio devices to re-assert the SCI when it is resampled, to make
sure that wakeup events which occur during suspend actually wake the
guest up. This is done by passing an Event as part of the VmRequest::Gpe
message, and re-asserting the SCI until the virtio device signals the
Event.
BUG=b:301862490
TEST=Manual test with ArcS2Idle feature flag
Change-Id: Ib2067e2cb6c41e886f3414e9a8c4e7c61048dfb9
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5491344
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: David Stevens <stevensd@chromium.org>
This avoids the need to clone the path when calling do_restore(). The
do_restore() function itself can convert the Path reference into an
owned PathBuf as needed, cleaning up the callers.
BUG=None
TEST=tools/dev_container tools/presubmit
Change-Id: Ie43813ee4299d44319bb907a645abc544c99dad4
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5506737
Reviewed-by: Frederick Mayle <fmayle@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Allow the RTC to un-suspend VCPUs, to wake the guest up from S3.
BUG=b:301862490
TEST=Manual test with ArcS2Idle feature flag
Change-Id: Ida9934d8c7caafc507dbadcc0c45ad5edbfd4b2d
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5491347
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: David Stevens <stevensd@chromium.org>
Introduces a new switch/option on snapshot commands/IPCs that turns on
encryption using the crypto crate.
BUG=b:286345300
TEST=builds upstream; tested end to end downstream.
Change-Id: Ia04074bb23332274d4e6b99eb242c84b0af7a8a9
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5371444
Reviewed-by: Frederick Mayle <fmayle@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Noah Gold <nkgold@google.com>
This CL introduces the USB backend device provider logic to handle
attaching security keys to the backend.
BUG=b:297957754
TEST=presubmit
Change-Id: I5849ad617b41a9d8ddb0127d9167ee02b27cd8da
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4945571
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Several crates still declared a dependency on data_model despite not
using any imports from it.
BUG=b:312312646
TEST=tools/dev_container tools/presubmit
Change-Id: I63a67696c205f684b1e4ac8bdad4de5f294b63dc
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5370964
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Spawn a stub_worker thread as a part of the device initialization to
avoid blocking PvClockCommand request when the device is not activated
yet. After this change, the requester of PvClockCommand can expect the
response from the device even if the device is not active. This can
happen when the guest kernel does not support the PvClock device and
because of that the device is not activated (from the virtio device
perspective).
BUG=b:295256641
TEST=cargo test -p devices -- pvclock
TEST=cargo test -p e2e_tests -- suspend
Change-Id: I0efc10bbf0e1125bf2df9208e1d6bcc341867a7e
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5312037
Auto-Submit: Hikaru Nishida <hikalium@chromium.org>
Commit-Queue: Hikaru Nishida <hikalium@chromium.org>
Reviewed-by: David Stevens <stevensd@chromium.org>
RAM snapshot size and overall snapshot time for a basic ubuntu VM right
after login:
* no compression: 619M 0.8s
* lz4 compression: 175M 1.2s
BUG=b:320753724
TEST=crosvm snapshot take --compress-memory /tmp/crosvm-snapshot /tmp/crosvm-control
Change-Id: I5dff9fe8744847fea872ad78347ac5f7d8b957e3
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5190788
Reviewed-by: Elie Kheirallah <khei@google.com>
Commit-Queue: Frederick Mayle <fmayle@google.com>
Reviewed-by: Noah Gold <nkgold@google.com>
Example command:
crosvm gpu set-mouse-mode <control_socket_path> \
--display-id=0 \
--mouse-mode=relative
This enables the Windows implementation to toggle mouse capture
mode (touchscreen <-> relative). It will have no effect if the
specified "display-id" doesn't point to an existing guest display
associated with an in-use host display.
BUG=b:324087519
TEST=presubmit
Change-Id: I9e513eb692d4b9cba66eb1e629ab8f7018645059
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5319794
Reviewed-by: Noah Gold <nkgold@google.com>
Commit-Queue: Pujun Lun <lunpujun@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Using serde_json on unbuffered readers/writers is slow.
Change-Id: Ie22f09e317d86d44263805e6f850ee96c0f0aa04
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5325901
Reviewed-by: Noah Gold <nkgold@google.com>
Commit-Queue: Frederick Mayle <fmayle@google.com>
Turns out impl Trait in return position means we only get *one* concrete
return type for all branches. In a future CL we'll have multiple return
types, so paradoxically, we'll have to think inside the Box.
BUG=b:326170473
TEST=builds
Change-Id: If759995d47e717adfeae6153f81f9940062e1e4e
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5320337
Reviewed-by: Frederick Mayle <fmayle@google.com>
Commit-Queue: Noah Gold <nkgold@google.com>
The current SnapshotReader/Writer interface returns Files for raw
fragments. When we add snapshot encryption, we will need to return an
encrypting or decrypting streaming wrapper, and this won't be a File.
This CL changes the interface to return impl Read or impl Write. As
part of that, we also had to make a significant safety change to
how memory snapshots are taken.
Memory snapshots used to be written with FileReadWriteVolatile. This is
because we assume GuestMemory is always mutably borrowed by the guest,
and it is UB to have aliased references in Rust. While formally
undefined, the rough reasoning for this is that LLVM optimizations
assume noalias on mutable references, and if that is violated at
runtime, optimizations can result in changed behavior. In the snapshot &
restore case though, we know the guest is not running because its VCPUs
are stopped, so its mutable reference can be ignored (temporal overlap
for aliasing is required for UB to occur). Luckily for us, the host code
will never alias guest memory because up until this CL, we assumed that
was never safe.
Credit: thanks to fmayle@, who originally proposed using Read/Write in this
manner in a CL that added snapshot compression.
BUG=b:326170473
TEST=builds
Change-Id: Iafd9175f684bc197329a0f5aae57685f5cfd677e
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5313630
Reviewed-by: Frederick Mayle <fmayle@google.com>
Commit-Queue: Noah Gold <nkgold@google.com>
Certain platforms use the noncoherent-dma feature to appropriately
consider the guest PAT's memory type (caching mode) when configuring the
effective memory type in SLAT, instead of simply ignoring it in favor of
the host PAT.
Dynamic blob mapping has already integrated support for noncoherent-dma
upon setting up each mapped blob's memory region (e.g. KVM memslot),
but fixed_blob_mapping merged while naively ignoring the feature.
Now, we respect the feature when setting up the shared/prepared memory
region (appropriately passing the new MemCacheType enum through to the
hypervisor).
BUG=b:246334944
TEST=tools/presubmit
TEST=(in venus-enabled VM w/ noncoherent-dma) `deqp-vk -n dEQP-VK.memory*` passing
TEST=(in venus-enabled VM w/ noncoherent-dma) Hollow Knight, Portal 2,
Valheim, CS:Source all look fine.
Change-Id: Ia31763c80765a42a1932bfb347ffa57a2faf6fab
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5285309
Commit-Queue: Ryan Neph <ryanneph@google.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Before this change, each guest synchronous virtio-gpu
VIRTIO_GPU_CMD_RESOURCE_MAP_BLOB submission would provoke crosvm's
hypervisor thread to perform a costly vMMU guestPA->hostVA mapping
(configure a new kvm memslot).
With this change, the entire Virtio-GPU PCI BAR address space can
optionally be pre-configured to a single vMMU mapping. Then, subsequent
RESOURCE_MAP_BLOB requests are handled by mmap() of the blob's exported
fd (dma-buf, shmem, ...) in the hypervisor process to a fixed hostVA
within an unused portion of the vMMU's pre-mapped region corresponding
to the blob's guestPA in the virtio-gpu device's BAR.
The new option is disabled by default, since this is not yet compatible
with the exposure of host dma_bufs to a PCI-passthrough device via
virtio-iommu + vfio. Those features are currently mutually exclusive
(i.e. PCI-Passthrough GPU must continue to use per-blob vMMU mappings
for now).
BUG=b:246334944
TEST=tools/presubmit
TEST=(in linux VM + venus): vkcube
TEST=(in linux VM + virgl): apitrace replay <opengl-game-trace-file>
Change-Id: Ibdd9ad8c12651cb7d31dd8648be9da17cc01cba3
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5255761
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Ryan Neph <ryanneph@google.com>
Make this cause of a failed "fixed mapping" attempt obvious when
inspecting the logs. This shouldn't be seen in production and is here
for developers that attempt to enable an incompatible VmMemorySource
type before it can be supported.
BUG=b:246334944
TEST=tools/presubmit
Change-Id: Ief32abc85d0aa07d4507a1d53f0ba55becca5e0f
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5255759
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Ryan Neph <ryanneph@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Inline a procedure that has only a single caller.
BUG=b:246334944
TEST=tools/presubmit
Change-Id: Ib727090c710162d16bdf4acf05e5b94c0e80e16a
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5255758
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Ryan Neph <ryanneph@google.com>
