When a write_zeroes call covers a whole cluster, we can deallocate the
storage for that cluster rather than writing zeroes.
This is currently implemented by removing the cluster allocation from
the mapping tables, then attempting to release the backing storage using
fallocate() with FALLOC_FL_PUNCH_HOLE.
BUG=chromium:850998
TEST=cargo test -p qcow
Change-Id: Ie4edb2e02bfaa1df9a19919b77eeb3c58c112d1c
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1187019
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Add a simple implementation of WriteZeroes for QcowFile that just
writes zeroes to allocated clusters and skips clusters that are already
unallocated (since they already read back as zeroes).
BUG=chromium:850998
TEST=cargo test -p qcow
Change-Id: I8f26c8cc4016c129850aaf08c7188dfe08d6dacb
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1187018
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
KVM_GET_MSRS may return less MSRs that were requested; do not fail but
instead let callers to know how many were fetched.
BUG=None
TEST=cargo test --features plugin
Change-Id: Ie14a3d38b66bfe34f5279543bea9c6c78423527e
Signed-off-by: Dmitry Torokhov <dtor@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1192232
Reviewed-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
KVM may not return all MSRs that were requested in KVM_GET_MSRS call and
instead stop early. We should handle this case.
BUG=None
TEST=cargo test -p kvm
Change-Id: I18402c0a07b1d0c7657c171873d521fd2f223611
Signed-off-by: Dmitry Torokhov <dtor@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1192231
Reviewed-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
We have to create irqchip in kernel before we are allowed to set up
routing.
BUG=None
TEST=cargo test -p kvm
Change-Id: Icee680ce3cc16af9cf4492c048f0b9b3cbe98d09
Signed-off-by: Dmitry Torokhov <dtor@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1192230
Reviewed-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
While fixing an unrelated bug in mosys' copy of this file, I found this
typo.
BUG=None
TEST=PreCQ
Change-Id: Icbb48864ad890fcd4f83c28203d187fcfdc648cc
Reviewed-on: https://chromium-review.googlesource.com/1194599
Tested-by: Jorge Lucangeli Obes <jorgelo@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Userspace is interested in number of supported MSRs even if supplied
buffer is too small, as then it can intelligently [re]allocate the
buffer and repeat the call instead of doing this blindly. So let's
always populate 'out_count'in crosvm_get_msr_index_list() call.
Obviously if there is hard error we will not be able to supply a
meaningful number, so 0 will be returned, but in case of E2BIG error we
can return the real number.
Also let's do the same for get_supported_cpuids() and
get_emulated_cpuids() calls.
BUG=b:111083877
TEST=cargo test -p kvm; cargo test --features=plugin
Change-Id: I37a8d719103fac44597b88ddecb6b8af2dd54ac8
Signed-off-by: Dmitry Torokhov <dtor@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1185293
Reviewed-by: Zach Reizner <zachr@chromium.org>
Seccomp policy for ARM hosts was recently moved from aarch64 to arm to
accurately match the ABI used on the host. Move 9s policy to match this.
BUG=none
TEST=vm.Webserver on kevin succeeds
Change-Id: I97daa524edcd411618561ce07525738bc65457cb
Reviewed-on: https://chromium-review.googlesource.com/1180470
Commit-Ready: Stephen Barber <smbarber@chromium.org>
Tested-by: Stephen Barber <smbarber@chromium.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
The bit that indicates a compressed cluster in the qcow2 format is
stored in the L2 table entry (cluster descriptor), but the code was
checking for it in the L1 table entry.
Spotted by inspection based on the qcow2 format documentation (QEMU
docs/interop/qcow2.txt).
This has no impact in normal crosvm use cases, since crosvm never writes
compressed clusters; the only case where it could have any effect would
be when using a QEMU-created qcow2 image with compressed clusters, which
would have returned incorrect data from a read instead of failing the
read request as intended.
BUG=chromium:874699
Change-Id: Ic247490dcac5440fab8e4d34d24ffe6fe9ab3110
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1176733
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Define a struct to represent the virtio block configuration as defined
in the current revision of the specification. Only the capacity field
is set; all other fields are defaulted to 0, which should be safe, since
they are all controlled by feature flags that our device does not
advertise.
This is prep work for adding discard/write zeroes support to the block
device, since these commands require additional config fields that will
be added at the end of the config struct.
BUG=chromium:850998
TEST=cargo test -p devices; verify that container still boots and
reports the correct size
Change-Id: I8beb76195e446eb3dcbf1a99cc246ddd8cc8a7df
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1175235
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
The virtio block specification defines the VIRTIO_BLK_F_RO feature bit
to indicate read-only block devices. Plumb the read-only status of
block devices from the crosvm frontend into the virtio block device and
populate the flag when appropriate.
BUG=chromium:872973
TEST=Verify lsblk output in guest has the correct RO values
Change-Id: I23af87cce8020641cd702adca6e8ff9fdd2b8220
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1170306
Reviewed-by: Zach Reizner <zachr@chromium.org>
This matches other virtio device models (net, p9, vsock) and makes it
easier to add flags conditionally at device creation time.
BUG=chromium:872973
TEST=cargo test -p devices
Change-Id: I65b3f37c220fae44a3f6b397acc6c0eec2b70bf2
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1170305
Reviewed-by: Zach Reizner <zachr@chromium.org>
This is more consistent with the way it will be used in the virtio-blk
device model.
BUG=chromium:872973
TEST=cargo test
Change-Id: I28c5d007a7f3864ef6e18e9b343d263123302484
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1170304
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Convert the definition of VIRTIO_BLK_F_FLUSH to a shift count instead of
a bitmask. This matches the way the features are defined in the virtio
spec and makes block consistent with other device models, such as p9.
BUG=chromium:872973
TEST=cargo test -p devices
Change-Id: Iece974c6f4d826b7bb76622973f08469a7936234
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1170303
Reviewed-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Device allocations have to skip the gap so they don't collide with
things like the APIC.
BUG=863490
TEST=Resize a gedit window on APL for a minute and make sure there isn't
a crash.
Change-Id: Ia8185bcdbb6c18e13d02be317ae4d48c73288661
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1168400
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Implement a new virtio_9p device to be used for sharing directories with
the VM.
BUG=chromium:703939
TEST=mount inside a VM and run `bonnie++ -r 256`
Append the shared directory to the crosvm command line:
--shared-dir /path/to/dir:test_9p
Then mount in the guest:
mkdir /tmp/9p
mount -t 9p -o trans=virtio test_9p /tmp/9p -oversion=9p2000.L
Or for a 9p root:
run --shared-dir /mnt/vm_root:/dev/root -p 'root=/dev/root ro rootflags=ro,trans=virtio,version=9p2000.L,cache=loose rootfstype=9p' vmlinux.bin
CQ-DEPEND=CL:1065170
Change-Id: I41fc21306ab5fa318a271f172d7057b767b29f31
Signed-off-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1065173
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Add the 9s crate, which provides an executable that can serve the 9p
file system protocol. It initially only supports connections over vsock
but can easily be extended to support network and unix domain socket
based connections.
BUG=chromium:703939
TEST=Run the server, have maitred connect to it over vsock, mount the
9p file system in the guest kernel, share it with the penguin
container, and run `bonnie++ -r 256 -s 512`
CQ-DEPEND=CL:1121550, CL:1166446
Change-Id: Ia0c72bcf29188bba4c07b6c0a2dd5a83d02339b5
Signed-off-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1112870
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Support macro derive(BitField) to make life easier.
BUG=None.
TEST=local build and run test.
Change-Id: I582620de250017fb7c0b601f9ad4fbcbbc2fe02a
Reviewed-on: https://chromium-review.googlesource.com/1069331
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Jingkui Wang <jkwang@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Plumb in KVM_GET_MSR_INDEX_LIST to allow clients to figure out what MSRs
are supported.
BUG=b:111083877
TEST=cargo test -p kvm
Change-Id: I69deba32a21fb9360f8cd53001d717338523fb71
Signed-off-by: Dmitry Torokhov <dtor@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1152228
Reviewed-by: Zach Reizner <zachr@chromium.org>
In future changes this state will be generated by the architecture, so
make it easier to pass around than 11 variable individually.
Change-Id: If2c5f15b429ef7b651f88bfa50aabcf47757c02b
Reviewed-on: https://chromium-review.googlesource.com/1099855
Commit-Ready: Dylan Reid <dgreid@chromium.org>
Tested-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Ensure eglImage is not destroyed until the referencing resource is dropped.
BUG=None
TEST=build with --features=gpu; null_platform_test
Change-Id: I55c33344f46b08f846e094451516fcd16c9d16ae
Reviewed-on: https://chromium-review.googlesource.com/1073958
Commit-Ready: David Riley <davidriley@chromium.org>
Tested-by: David Riley <davidriley@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
In preparation of adding fence support, allow process_descriptor to
defer returning the descriptor until later by returning None.
BUG=None
TEST=build with --features=gpu; null_platform_test
Change-Id: I57e4dc438e7f5a925c870e0bd596f89a2ed4e083
Reviewed-on: https://chromium-review.googlesource.com/1073957
Commit-Ready: David Riley <davidriley@chromium.org>
Tested-by: David Riley <davidriley@chromium.org>
Reviewed-by: David Riley <davidriley@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Add serial bus subclass
BUG=chromium:831850
TEST=cargo test
Change-Id: Iffd7a27b5cb423c928f0108b16fb58558cf7bcd4
Reviewed-on: https://chromium-review.googlesource.com/1152212
Commit-Ready: Jingkui Wang <jkwang@google.com>
Tested-by: Jingkui Wang <jkwang@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Implement a policy for the balloon device so that it starts taking
memory away from the VM when the system is under low memory conditions.
There are a few pieces here:
* Change the madvise call in MemoryMapping::dont_need_range to use
MADV_REMOVE instead of MADV_DONTNEED. The latter does nothing when
the memory mapping is shared across multiple processes while the
former immediately gives the pages in the specified range back to the
kernel. Subsequent accesses to memory in that range returns zero
pages.
* Change the protocol between the balloon device process and the main
crosvm process. Previously, the device process expected the main
process to send it increments in the amount of memory consumed by the
balloon device. Now, it instead just expects the absolute value of
the memory that should be consumed. To properly implement the policy
the main process needs to keep track of the total memory consumed by
the balloon device so this makes it easier to handle all the policy in
one place.
* Add a policy for dealing with low memory situations. When the VM
starts up, we determine the maximum amount of memory that the balloon
device should consume:
* If the VM has more than 1.5GB of memory, the balloon device max is
the size of the VM memory minus 1GB.
* Otherwise, if the VM has at least 500MB, the balloon device max is
50% of the size of the VM memory.
* Otherwise, the max is 0.
The increment used to change the size of the balloon is defined as
1/16 of the max memory that the balloon device will consume. When the
crosvm main process detects that the system is low on memory, it
immediately increases the balloon size by the increment (unless it has
already reached the max). It then starts 2 timers: one to check for
low memory conditions again in 1 seconds (+ jitter) and another to
check if the system is no longer low on memory in 1 minute (+ jitter)
with a subsequent interval of 30 seconds (+ jitter).
Under persistent low memory conditions the balloon device will consume
the maximum memory after 16 seconds. Once there is enough available
memory the balloon size will shrink back down to 0 after at most 9
minutes.
BUG=chromium:866193
TEST=manual
Start 2 VMs and write out a large file (size > system RAM) in each.
Observe /sys/kernel/mm/chromeos-low_mem/available and see that the
available memory steadily decreases until it goes under the low memory
margin at which point the available memory bounces back up as crosvm
frees up pages.
CQ-DEPEND=CL:1152214
Change-Id: I2046729683aa081c9d7ed039d902ad11737c1d52
Signed-off-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1149155
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Descriptor chains of three descriptors were not having the last
descriptor parsed correctly which resulted in some commands not
properly being responded to.
BUG=None
TEST=build with --features=gpu; null_platform_test
Change-Id: Ia77c7ca485ded7cdcb71fd62e8f6be5c226df1bf
Reviewed-on: https://chromium-review.googlesource.com/1073956
Commit-Ready: David Riley <davidriley@chromium.org>
Tested-by: David Riley <davidriley@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
The original methods for reading and writing to GPU buffers naively
assumed that the mappings returned by GBM were to the first byte in the
buffer. In fact, the returned mapping is to the first pixel of the
mapped rectangle. This would lead to segaults when the copy routine
would breeze past the end of the mapping into segault territory.
This change fixes the read and write algorithms and adds lots more guard
rails in to prevent future undefined behavior (hopefully).
TEST=boot kernel with VT and VIRTIO_GPU
BUG=None
Change-Id: Ia7c968b6dd274551b6d218e2f0b255af6e55bd35
Reviewed-on: https://chromium-review.googlesource.com/1102110
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
The size is specified in bytes, correct the help messages.
Change-Id: I386b329123bbfc9dfdaf073eb345c4554ade4982
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1145763
Reviewed-by: Stephen Barber <smbarber@chromium.org>
PCI devices will require interrupts, allow this by passing a vector of
IRQs to the mptable so the guest kernel can find the IRQs.
Change-Id: I9fa8a2ed0a34089e631441570521082ffde9c4ef
Reviewed-on: https://chromium-review.googlesource.com/1072578
Commit-Ready: Dylan Reid <dgreid@chromium.org>
Tested-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
These policies are not for aarch64 but use the 32-bit system calls.
We call it aarch64 support because that's what we're targetting for
the guest kernel, but it doesn't really make any sense to call the
seccomp policies aarch64 when we're building a 32-bit binary.
We can add real aarch64 seccomp policies when we start building a
aarch64 crosvm binary.
BUG=chromium:866197
TEST=emerge-kevin crosvm, run vm_CrosVmStart
CQ-DEPEND=CL:1145903
Change-Id: I7c5e70fbc127e4209ed392cfcf10ea36a6dd4b2c
Reviewed-on: https://chromium-review.googlesource.com/1145909
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
These syscalls were added to the x86 policy when vfd pipe support was
added, but they were never added to the arm version, for whatever
reason. This is needed to keep crosvm from getting killed by SIGSYS
whenver the user copies to or from guest applications.
BUG=chromium:864218
TEST=on kevin, copy/paste to/from gedit
Change-Id: Ibe385d50e367c362e911badd640bab2c98e07030
Reviewed-on: https://chromium-review.googlesource.com/1145876
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Basic 2D and 3D support is there. The drm_cursor_test and
null_platform_test in drm-tests should run to completion.
The extra device is hidden behind both a build time feature called 'gpu'
and the device is only added to a VM if the '--gpu' flag is given.
TEST=build with --features=gpu;
drm_cursor_test && null_platform_test
BUG=chromium:837073
Change-Id: Ic91acaaebbee395599d7e1ba41c24c9ed2d84169
Reviewed-on: https://chromium-review.googlesource.com/1036862
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
These bindings are needed for virtio-gpu 3D capabilities.
All the rust files under gpu_renderer/src/generated are generated via
the gpu_renderer/src/generated/generate script.
The gpu_renderer/src/lib.rs file contains the Renderer and Context
structs, which are the main interfaces to virglrenderer. They
encapsulate the global state of virglrenderer (Renderer) and each
context ID (Context).
The command_buffer module is included only for basic testing and is not
intended for production use.
The pipe_format_fourcc module is provided for the conversion of
virglrenderer specifc formats to standard fourcc formats.
BUG=chromium:837073
TEST=cargo build -p gpu_renderer
CQ-DEPEND=CL:1144406
Change-Id: Iad153390f618309bf493e92e76432c0b1c4a8a93
Reviewed-on: https://chromium-review.googlesource.com/1043447
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
`PciRoot` represents the root PCI bridge for the system and manages PCI
devices attached to it. The root bridge has its own set of configuration
registers.
Change-Id: I2b15630cf5a0fc5938e66986a65782c6939fcf55
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1072577
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
PCI adds a configuration space to the existing memory mapped IO
supported by BusDevices.
Add the ability to set configuration space as optional to the BusDevice
trait so that ProxyDevice can be shared.
PCI devices can have more than one memory mapped region. Expand the bus
so that it has the ability to pass an absolute address instead of an
offset. This will allow the PCI device to know which BAR is being
written to.
Change-Id: I055cd516c49a74316a9547df471290f05d865b0a
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1103663
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
ARM cares about the status so we need to parse the request correctly and
fill in the status.
Change-Id: I1ffabf556424184017eb64d3b9c68c72b75d0a26
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1139584
Reviewed-by: Stephen Barber <smbarber@chromium.org>
