Since we default to podman, we can get rid of the _user container and
run as root inside the container, which greatly simplifies the tooling.
This also allows us to provide a single, default devcontainer.json
for local development as well as codespaces.
podman can be used with this devcontainer.json as well, e.g. in
VSCode by setting:
"dev.containers.dockerPath": "podman"
The with_kvm/devcontainer.json can be used to add access to kvm, which
may not be available on all machines. So it's an optional config.
BUG=b:273529620
TEST=Open with devcontainer in VSCode with both docker and podman,
run `presubmit --no-delta`
TEST=tools/dev_container tools/presubmit --no-delta
Change-Id: I10e04898a0e1adb6e4939f6f2e0259dc9b9aa62d
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4419666
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Zihan Chen <zihanchen@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
gfxstream has transitioned to simpler ways to configure the renderer,
use them.
BUG=278138335
TEST=launch_cvd
Change-Id: If0918495c2683cd2d99ed5c49c6bf01dd2edfe5f
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4470287
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Allow the `cfg` field of RunCommand to be used in configuration files,
providing a mechanism for configuration inclusion.
Configurations are merged in the following order: first the included
files by order of specification (recursively), then the parent file,
then finally the other command-line arguments.
BUG=b:218223240
TEST=booted a VM with a configuration file that included another one and
confirmed both settings were applied.
Change-Id: I0c1e1b12b7c329510d450069e2e9de5b52af7734
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4414504
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Some features present on aarch64 and x86 aren't yet on riscv, add
conditional compile checks.
Change-Id: Ie29e0b7b78af1cb43c04fa1e22c48645c2de8386
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4460934
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Add initial KVM bindings generated from a 6.2 tree with the AIA patches
applied.
See the riscv_kvm_aia_v1 branch here: https://github.com/avpatel/linux
The AIA changes should land soon upstream, but pulling them in early
won't hurt other arches and will allow riscv to get started.
Change-Id: I9e20c968e6c044100bc6ec1b2fb5f441f0276f77
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4460933
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Later commits add basic support for riscv64 builds. This commit re-adds
the checks for compilation of debug output that were present before
aarch64 was ready. This allows unsupported architectures to build, even
if they don't have graphics support yet.
Change-Id: I42f2aadfed709378173ff6a6414c2896cc685baf
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4460932
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
This ioctl has been long deprecated and is removed from 6.2+ kernels.
It's not used by crosvm so this change should have no affect.
Change-Id: Ieb1b7c1772643d221356ca1ecb8f6a32095febba
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4460931
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
The previous maximum size was 64K minus 1 byte; this also did not leave
room for the request/response header, so the actual maximum transfer
size in a single request was slightly smaller.
Use 64K + 24 bytes, since this matches the P9_IOHDRSZ subtraction used
by the Linux 9p client to calculate the maximum I/O size.
BUG=b:265610073
TEST=strace 9s on host and verify larger read()/write() syscalls
Change-Id: Ia606222d3c52a7a6e3f6cfca1a9fcbd78e223855
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4455812
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
The iounit value is meant to be an upper limit on the size of each I/O
sent by the client: <https://9p.io/magic/man2html/2/iounit>
Previously, we used the stat() st_blksize value for iounit; this caused
the Linux 9p client to split up every read/write request into 4096-byte
chunks in the usual case of an ext4 host filesystem, which causes very
low performance.
Report iounit=0 instead, which will allow the client to send Tread and
Twrite requests up to the negotiated msize (maximum message size).
BUG=b:265610073
TEST=strace 9s on host and verify larger read()/write() syscalls
Change-Id: I86341998f440ac1c567da7d8fc6e740189ccb44a
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4455811
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
gfxstream has transitioned to consistent APIs and a simpler
fence API. Use it.
BUG=b:278138335
TEST=launch_cvd
Change-Id: I91a55021b79c65e057fca5891e64c023ba5cab0b
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4428537
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
When we restore a snapshot, we need to refresh the set of Events that
the IRQ handler thread is listening on, otherwise it won't forward IRQs
from the restored/re-created events.
BUG=b:277651574
TEST=tools/dev-container e2e_tests/run
Change-Id: Icd61112c23f063af0f6f217efe2b3359f884e351
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4416558
Reviewed-by: Steven Moreland <smoreland@google.com>
Reviewed-by: Elie Kheirallah <khei@google.com>
Commit-Queue: Noah Gold <nkgold@google.com>
Reviewed-by: Richard Zhang <rizhang@google.com>
Now that RunCommands can be merged several times without ambiguity,
allow the `--cfg` argument to be used several times, allowing to augment
a base configuration with others. Configurations are merged in their
order or specification, with the other command-line arguments being
merged last.
BUG=b:218223240
TEST=added test passes, booted a VM while specifying `--cfg` several
times.
Change-Id: I94d4f02e403db0203a2757e78a5932805c6d8387
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4414503
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
We recently enabled configuration files with the limitation that only
one file could be specified, and configuration files cannot include
further files. This limitation was due to the fact that the argh crate
could not handle Option<bool> as switches, which forced us to use bool,
which cannot be merged unambiguously more than once.
argh 0.1.10 now allows to use Option<bool> for switches, which will
allow us to lift these limitations. Start by converting all bools in
RunCommand into Option<bool>, and mandating that all members of
RunCommand are either Option or Vec. Following CLs will implement the
features that doing so enables.
BUG=b:218223240
TEST=presubmit
Change-Id: Ica19c94b9509aec7145a6af954d3ebe04a73bc3d
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4414502
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
We want support for #[switch] on Option<bool> in order to support
specifying several configuration files. This feature has been merged in
0.1.10.
BUG=b:218223240
TEST=cargo build
Change-Id: I4f1a2474f797907fbd180b0ebe67d87ea7920b46
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4414501
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Add Podman as an option in building crosvm.
Have `Example Usage` point to `Custom Kernel/Rootfs` for preparing a
custom kernel/rootfs, instead of building crosvm.
BUG=N/A
TEST=mdbook build && check the html page
Change-Id: I920526c01140439c416e929d4711ae996bb0831e
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4455448
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Auto-Submit: Elie Kheirallah <khei@google.com>
Commit-Queue: Elie Kheirallah <khei@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
The virtio-pci device uses ioevents to monitor the notification region
of its BAR for guest-initiated kicks. This is not necessary until the
queues are actually started, so we can remove the ioevents() function
and instead use the existing VmMemory requests to add and remove the
ioevents when the device is activated or stopped/reset.
This avoids the need to remove and re-add the ioevents for the queues
during PCI device initialiation, where the guest may repeatedly disable
and re-enable memory decode.
BUG=b:278130202
TEST=Boot Crostini and ARCVM on x86_64 and aarch64
TEST=tools/dev_container tools/presubmit
Change-Id: I22e0b5a84c8cc9c4f60807624610dbbcabf982cc
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4425869
Reviewed-by: Noah Gold <nkgold@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Ningyuan Wang <ningyuan@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
BUG=b:244553205
TEST=Patched into AOSP and ran some VMs.
Change-Id: I95710fdb264a3bd1e8e69ed6dfad77bbc05b3043
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4440589
Reviewed-by: Jiyong Park <jiyong@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Pierre-Clément Tosi <ptosi@google.com>
Commit-Queue: Andrew Walbran <qwandor@google.com>
Deprecate the crosvm_direct field in build_linux.proto and remove the
code that used it in build_linux.py.
BUG=b:276993009
Change-Id: I1c48064391f3201ad6e27bf9dbfe33e705477672
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4437033
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Auto-Submit: Daniel Verkamp <dverkamp@chromium.org>
wait_for_handle always returned 0.
Timer::next_val's return wasn't used and its meaning was platform
dependent.
Change-Id: I2278859c19505398c3dd01b90e69e20894c38e25
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4409940
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
`wait_for_handle` only makes sense on Windows.
`read_u64` can be implemented in terms of the other read methods. We now
have to allocate a `Vec` which shouldn't technically be needed for the
epoll backend. We do this for all other kinds of IO and timers/events
are generally low throughput, so expect the performance loss won't be
noticable.
Change-Id: I1c1f1d5d1fc84073b940bc71425fe150196c4441
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4405314
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
If a guest wants to lookup() a file on virtiofs with ascii_casefold
enabled, ascii_casefold_lookup() in PassthroughFs collect file names in
a directory by calling getdent64() repeatedly. This operation is
expensive especially when many files are contained in the directory.
To improve performance of this operation, this CL add a cache for
dentries, will be invalidated after a certain time.
This cache is especially useful when the guest lookup() files repeatedly
in a directory containing many files.
Here is the results of "vm.ManyFiles.virtiofs_casefold" with and without
this CL. We observed significant improvements on create() and nagative
lookup() against huge number of files.
(millisecond) | current | w/ CL
-----------------------------------
create | 223506 | 11794
open | 7559 | 7526
negative lookup | 208102 | 3702
remove | 15173 | 15063
We didn't observed performance changes for vm.ManyFiles.virtiofs (no
casefold) and arc.RuntimePerf.sniper3d_virtiofs_vm.
See go/crosvm-virtiofs-casefold-cache-evaluation for the detailed
results.
BUG=b:263475037
TEST=cargo nextest run
TEST=tast run vm.ManyFiles.*
TEST=tast run arc.RuntimePerf.sniper3d_virtiofs_vm
Change-Id: Ida191a96d63ef3a95ae3dcae12a973870fafa2a0
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4160474
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Takaya Saeki <takayas@chromium.org>
Reviewed-by: David Stevens <stevensd@chromium.org>
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
Avoid potential overflow when adding the base and length of a range by
using saturating addition.
If the total of range base and length exceeds the size of a u64, this
usually indicates an incorrect range, but using saturating adds allows
us to handle this gracefully rather than causing a panic when checked
arithmetic is enabled.
BUG=b:274366589
TEST=tools/dev_container tools/presubmit
Change-Id: I358d906718d3e8c2d7a5c72721b095199fc785cb
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4356903
Reviewed-by: Zihan Chen <zihanchen@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
basically the same as the existing balloon_stats command, allows for
querying of a balloon working set size from the command line using the
crosvm binary and the control socket of a running vm.
TEST=run bzImage, issue command
BUG=b/278120533
Change-Id: I1fc41f91622aebd8a413fd029d84da4cf651daec
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4434049
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Maciek Swiech <drmasquatch@google.com>
since run_control is single threaded, we should be able to always
discard stale wss/stats messages in the handlers in vm_control,
obviating the need to keep a separate tube for wss crosvm_commands.
BUG=None
TEST=run bzImage
Change-Id: I7de192a08ae7a42641cbabe183dbad1c6ef627a4
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4428055
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Maciek Swiech <drmasquatch@google.com>
Remove the extra [[bin]] from Cargo.toml, as it is no longer used by the
chromeos-base/crosvm ebuild.
The "direct" feature is kept for now, since some of the functionality
behind that flag may still be useful (and should be moved to separate
features rather than "direct" eventually).
BUG=b:276993009
TEST=cargo build
TEST=tools/dev_container tools/presubmit
Change-Id: I78269d94913a216ebfb7f22ddc58d9cfdb6a6791
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4436629
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
The vhost kernel API is specific to Linux; it doesn't make sense to
build it on Windows.
Change-Id: I3b8f726f74389f2a3ff78eff43b0c4f312382004
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4437030
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
balloon size is useful for balloon policies using working set size, so
we return the balloon-device cached balloon size. unless there is some
error in adjustement of the balloon, this should reflect that real
balloon size and saves having to query the guest an additional time.
BUG=b/278119213
TEST=run bzImage
Change-Id: I7c6b558358b8db099a737430e8431997bb110b2b
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4428532
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: T.J. Alumbaugh <talumbau@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Auto-Submit: Maciek Swiech <drmasquatch@google.com>
Some `as usize` casts are necessary on non-glibc C libraries, since the
type of `cmsg_len` and `msg_controllen` may not be usize in the libc
bindings, so these warnings are suppressed instead of removing the
casts.
BUG=b:276487055
TEST=tools/clippy # with Rust 1.68
Change-Id: I30d9a16d37710b1356cffc183a03f8c8f6f35680
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4391102
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
The StreamMsg type contains a DescriptorChain, which is large enough to
cause clippy warnings about large Result values. Box the StreamMsg so it
is heap allocated instead to silence the warnings.
BUG=b:276487055
TEST=tools/clippy # with rust 1.68
Change-Id: I0e6ebd6e0e33d8fba2396f0923aed1ed8e99c13b
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4412659
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
This is a reland of commit 22c212d54f
This reland avoids using the new pre-mapped memory regions on arm
devices, since there is insufficient address space. The new path is
still used on aarch64.
Original change's description:
> vm_control: reduce user memory region modifications
>
> Reduce how often KVM_SET_USER_MEMORY_REGION is called when the tdp mmu
> is enabled. With the tdp mmu, there is no memory overhead from creating
> large memory regions (at least until a nested VM is started). Simply
> mmap'ing/munmap'ing fds within a pre-created memory region is more
> efficient. It also addresses audio jank caused by removing a memory
> region.
>
> Adding this support to VmMemoryRequest will allow FsMappingRequest to be
> removed in a later change.
>
> BUG=b:274037632
> TEST=tast run arc.Boot.vm
> TEST=manually launch gedit in crostini
>
> Change-Id: I2ac02454ecb734c9707b6d67546135134b887527
> Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4402068
> Reviewed-by: Dennis Kempin <denniskempin@google.com>
> Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
> Commit-Queue: David Stevens <stevensd@chromium.org>
Bug: b:274037632
Change-Id: I5deedfd3a030640f9af950cee675fac0d9a411a0
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4421352
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
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>
Normally, writes to the virtqueue notification region should be handled
via ioevents and not make it into the write_bar() handler. However, in
an upcoming change, ioevent registration will be deferred until
activate(), and in this case, it is possible that a queue is notified
while the ioevent registration is still in progress. To handle this
case, add a fallback to the VirtioPciDevice::write_bar() function to
signal the corresponding queue event. (These processes can overlap
because the BAR writes used to configure the virtio-pci device are
posted, meaning the guest does not need to wait after writing the
configuration register to activate the device and writing to a queue
notification region to start using a queue.)
BUG=b:278130202
TEST=crosvm run bzImage # observe working virtio devices
Change-Id: Ic1b19ac54f6dace29705b9d190d280eb5e962b5e
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4422465
Reviewed-by: Ningyuan Wang <ningyuan@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
I'm a bit baffled how this worked before - queue_evts is filled at
device creation time (before sandboxing) and used during activate()
(after sandboxing), so their file descriptors need to be preserved when
forking for the sandbox jailing process.
BUG=b:278130202
TEST=crosvm run without --disable-sandbox; observe /proc/N/fd of devices
Change-Id: Icde695fba5b015c84769e3dadedfe509c3fbaf19
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4422464
Reviewed-by: Ningyuan Wang <ningyuan@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
This matches the latest gfxstream declarations. Having
everything as a single enum without separation between
fence/mem isn't too bad since adding a new type essentially
means creating a new OS (which happens rarely).
BUG=b:273555494
TEST=compile
Change-Id: I6c6dd957e443cb51c3c8109d514d15985636a2b3
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4425451
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
This reverts commit 22c212d54f.
Reason for revert: Suspected to break crostini http://go/bbid/8783938922329906785
Original change's description:
> vm_control: reduce user memory region modifications
>
> Reduce how often KVM_SET_USER_MEMORY_REGION is called when the tdp mmu
> is enabled. With the tdp mmu, there is no memory overhead from creating
> large memory regions (at least until a nested VM is started). Simply
> mmap'ing/munmap'ing fds within a pre-created memory region is more
> efficient. It also addresses audio jank caused by removing a memory
> region.
>
> Adding this support to VmMemoryRequest will allow FsMappingRequest to be
> removed in a later change.
>
> BUG=b:274037632
> TEST=tast run arc.Boot.vm
> TEST=manually launch gedit in crostini
>
> Change-Id: I2ac02454ecb734c9707b6d67546135134b887527
> Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4402068
> Reviewed-by: Dennis Kempin <denniskempin@google.com>
> Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
> Commit-Queue: David Stevens <stevensd@chromium.org>
Bug: b:274037632
Change-Id: Id5caebd0bd33f4984567ff604f117ae4d95a71ab
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4422453
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
