When the V4L2 output queue is streamoff, crosvm gets QueueClear
command. All the V4L2 output buffers are dropped, but VDA doesn't drop
output buffers at this point. We should only clear the enqueued
resource ids, and not clear the whole output resources.
BUG=b:181541291
TEST=android.media.cts.AdaptivePlaybackTest
TEST=com.google.android.exoplayer.gts.DashTest
Change-Id: I343b809e80d5bc56679b76baa5593aebb4558a74
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2756068
Tested-by: Chih-Yu Huang <akahuang@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Chih-Yu Huang <akahuang@chromium.org>
This change is to cleanup some dead_code warnings that appear if certain
features aren't enabled.
This also updates the Cargo.lock when changed due to zeroize being added
to libchromeos-rs.
TEST=cargo check --all-features
BUG=None
Change-Id: I5347b584a7426dc37f3933b1e907b23a71145749
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2753128
Reviewed-by: Allen Webb <allenwebb@google.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Zach Reizner <zachr@chromium.org>
Commit-Queue: Zach Reizner <zachr@chromium.org>
This change is similar to http://crrev.com/c/2736520, which made the
path of the KVM device configurable. Similarly, most users will want
to keep the default paths of `/dev/vhost-vsock` and `/dev/vhost-net`.
In certain environments, namely Borg, those device nodes may be located
elsewhere.
BUG=None
TEST=./ci/builder --vm ./run_tests
Change-Id: I4bd7944d8f84fc0e7d255a3930c27f48a980e617
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2749235
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Set the SECBIT_NO_SETUID_FIXUP securebit so that we don't lose
capabilities when changing the thread uid/gid. This allows us to
simplify the create and mkdir functions so that all the checks we
currently carry out are only done once by the host kernel.
To ensure that the setuid and setgid bits still get dropped when a file
is modified by a process that doesn't hold CAP_FSETID, check for
WRITE_KILL_PRIV in the write flags and temporarily drop CAP_FSETID when
it is set.
BUG=none
TEST=Check that default posix acls, setgid bits, and file/directory
creation via membership of a supplementary group all work as
expected.
Change-Id: I420484e357a970e997cb3e968a433278e82d8ad4
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2684067
Auto-Submit: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Make the forked child processess easier to distinguish.
Also tweak the debug_label for virtio-pci devices so that more of the
name can fit into a limited-length thread name.
BUG=None
TEST=pstree
Change-Id: I74a8c1f5ab869e814bed4f2bd71c3de5179f7855
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2740526
Reviewed-by: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Crosvm pre-allocate mmio for device, but it doesn't enable memory/io
space in pci command config register, then OVMF doesn't use the pre-allocated
mmio and reallocate device mmio.
BUG=b:179053182
TEST='crosvm run -bios OVMF.fd' and check device info in efi shell
Change-Id: I7176e7f9716d829efff1ea023666eb705b525e5c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2741920
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
All virtio devices have virtio version 1.0 as base feature, but this revision
id isn't in pci configuration register, then OVMF won't start virtio 1.0
driver, and virtio device couldn't be used in OVMF.
BUG=b:179053182
TEST='crosvm run -bios OVMF.fd' and check virito blk device in EFI shell.
Change-Id: I8cbcd71b9b6ccef07b56853b7450b74e4dcbae1b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2741919
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
To track arc in VM in UMA and to separate it
from other linux VMs.
Changes:
- Add client_type options to Ac97Parameters.
- Add client_type option for the ac97 devices with CRAS backend.
BUG=b:177393225
TEST=Apply full patch set and start audio in ARCVM with
`cras_test_client --dump_a`
Cq-Depend: chromium:2744525
Change-Id: I27201aa65baed0ee59cf689dd7f22b5b91f00946
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2744968
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: Chih-Yang Hsia <paulhsia@chromium.org>
Commit-Queue: Chih-Yang Hsia <paulhsia@chromium.org>
While a host virtio device provides |num_queues| virtqueues, a guest virtio driver doesn't necessarily use all of them. For example, the virtio-blk driver uses only |nr_cpu_ids| virtqueues at most [1].
To avoid checking whether each queue is ready in each device implementation, we can filter them before starting device activation.
[1]:
https://patchwork.kernel.org/project/linux-block/cover/1553682995-5682-1-git-send-email-dongli.zhang@oracle.com/
BUG=b:179671351, b:181753022
TEST=CQ
Change-Id: I29d21d8d9db2d99aa9591ca55c18d06d2368797e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2732735
Tested-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Add #[repr(packed)] to struct virtio_blk_config to make its size same with the
the origianl C struct. The packed annotation will remove 4-byte padding at the
end of the struct and make the size of the struct smaller. (64 bytes -> 60 bytes)
Since it won't affect offsets of any fields, it shouldn't change any behavior
when the guest reads a config field. But, it can matter when the entire config
struct is passed via vhost-user protocol.
BUG=none
TEST=run a VM
Change-Id: I4dca9f1bdd93166192eca4d05d542ce851852aa7
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2726059
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
After the userspace streamoff the input queue, the crosvm should not
return the previous frames. However, VDA might still return frames
before notifying reset is done. This CL drops the decoded frames after
calling VDA::Reset() until reset is completed.
BUG=b:181087034
TEST=android.media.cts.AdaptivePlaybackTest
Change-Id: Ieaa40ef27f1b37a262c80f9f30698c03ef16bdb9
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2728584
Tested-by: Chih-Yu Huang <akahuang@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Chih-Yu Huang <akahuang@chromium.org>
When the video is flushed, V4L2DecodeComponent streamoff V4L2 output
and input queue. Then crosvm releases all output buffers and calls
VDA::Reset(). However, VaapiVDA implementation doesn't release output
buffer at Reset(). If Vaapi decodes the following frame before
V4L2DecodeComponent QBUF any output buffer, then crosvm will drop the
decoded frame.
This CL makes crosvm postpone sending the decoded frame if this
situation happens. Crosvm would sends the decoded frame when receiving
the buffer again.
BUG=b:181087034
TEST=emerge-hatch-arc-r crosvm
TEST=android.media.cts.AdaptivePlaybackTest
TEST=seek video many times and check no error occurs at the end of video
Change-Id: I0c8e59e2a206d6b2cd2009fd70380e7d5a366953
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2719245
Tested-by: Chih-Yu Huang <akahuang@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Chih-Yu Huang <akahuang@chromium.org>
Originally, process_cmd function can only return the response of the
procesesed cmd. However, we need to return the response of events for
some commands. This CL makes the process_cmd function could return
the responses of both command and event.
BUG=b:181087034
TEST=emerge-hatch-arc-r crosvm
Change-Id: Ie781795f8cee1c66e8462c602f876043b0dea9bc
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2719244
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chih-Yu Huang <akahuang@chromium.org>
Originally process_cmd() return VideoResult<VideoCmdResponseType>.
However, VideoCmdResponseType could return the error result by
Sync(CmdResponse::Error). VideoResult is not needed.
This CL change the returned type of process_cmd() to
VideoCmdResponseType to reduce code complexity.
BUG=b:181087034
TEST=emerge-hatch-arc-r crosvm
Change-Id: I1795a3eb09fe36076f5ad43fdd8d1eb9e21ffcd9
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2731607
Tested-by: Chih-Yu Huang <akahuang@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Chih-Yu Huang <akahuang@chromium.org>
- Add an address space region for the protected KVM firmware.
- Query firmware size, mmap something that size and create a memslot.
BUG=b:163789172
TEST=cargo test
Change-Id: I054cf5d763c980d073c17bce70e85a781816b64d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2623942
Auto-Submit: Andrew Walbran <qwandor@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Andrew Walbran <qwandor@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
In a long-running system, there is no reason to expect that a
significant number of freed pages are consecutive. However, batching is
relatively simple and can result in significant gains in a newly booted
system, so it's worth attempting.
BUG=None
TEST=arc.Boot.vm
Change-Id: Ia7dff4ab095d640a2a23ac4976bc277b09d9ea79
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2666412
Commit-Queue: David Stevens <stevensd@chromium.org>
Tested-by: David Stevens <stevensd@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
The max values for the multitouch slot ID and tracking/finger IDs were
set to zero previously, making it impossible to track multiple
fingers. This CL updates the max values to allow for 10 MT contact
points.
BUG=None
TEST=applied known working code from another branch.
Change-Id: Ic2e9919c2b83368eb1bc2085122c672fdafbdc84
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2708669
Reviewed-by: Tristan Muntsinger <muntsinger@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Noah Gold <nkgold@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Auto-Submit: Noah Gold <nkgold@google.com>
When the file system implements zero message open support, the file
handle is meaningless and it needs to know the inode of the
file/directory on which the ioctl was called.
BUG=b:180565632
TEST=lsattr, chattr, both work when zero message open is enabled.
Android's FileBasedEncryptionPolicyTest[0] gets ENOTTY as an error
instead of EBADF
[0]: bfbc00c20d/tests/tests/security/native/encryption/FileBasedEncryptionPolicyTest.cpp
Change-Id: Ic55ee95df928d645874dd8a9c7dc579b708927fa
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2706370
Tested-by: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Auto-Submit: Chirantan Ekbote <chirantan@chromium.org>
Commit-Queue: Stephen Barber <smbarber@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Reviewed-by: kokoro <noreply+kokoro@google.com>
Handle data offset for input bitstream buffers, as it is sometimes used
to skip headers at the start of buffers.
BUG=b:174531173
TEST=android.media.cts.MediaDrmClearkeyTest#testClearKeyPlaybackMpeg2ts
Change-Id: I6beee5cde24803ba90638c1dc130b75466f4847d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2692676
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: David Stevens <stevensd@chromium.org>
This is the original CL with one minor exception: we don't bind
mount the camera socket with the GPU device. That was the prior
behavior, and for some reason it really doesn't work with Mali +
SECCOMP[1]. It's not really important for the Wayland prototype,
so we'll let the camera team figure it out if and when they are
so inclined.
Bug: b:146066070
Bug: b:173630595
Bug: b:150239451
Bug: b:180126126
TEST=arc.Boot.vm
[1] audit(1613339319.226:43): auid=4294967295 uid=603 gid=603
ses=4294967295 subj=u:r:cros_camera_algo:s0 pid=17107
comm="cros_camera_alg" exe="/usr/bin/cros_camera_algo" sig=31
arch=40000028 syscall=54 compat=1 ip=0xe86a70b8 code=0x0
This reverts commit 51e1c4ad3e3a71a263501d2566d3b1ea59ba2070.
Change-Id: I74f49ece55656d7a9096900e3f19a528234b4224
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2695550
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Robert Tarasov <tutankhamen@chromium.org>
Enable the ZERO_MESSAGE_{OPEN,OPENDIR} features when the cache policy is
"always". This feature allows the kernel to skip the open message after
a successful lookup, reducing the amount of work that the server does.
This is implemented by changing the file descriptors stored in the
InodeData from O_PATH fds to O_RDONLY fds for files and directories.
Other types of directory entries (symlinks, special files, etc) still
use O_PATH fds.
If the kernel sends a write request for an fd opened in read-only mode
or a read request for an fd opened in write-only mode (can happen when
creating a new file), then we open a new fd in read-write mode before
performing the read/write. This only needs to happen the first time we
get a request that doesn't match the open flags.
This change should improve performance of opening and reading many small
files. It improves the blogbench read score by ~40% but reduces the
write score by ~25%. It also reduces the work done by the virtio-fs
server when loading roblox. The first load time is reduced by
~17% (3.04 seconds -> 2.52 seconds) and non-initial load times are
reduced by 50% (0.3 seconds -> 0.15 seconds).
BUG=none
TEST=vm.Virtiofs, vm.Blogbench.virtiofs, arc.PlayStore.vm, load roblox
inside arcvm
Change-Id: I042246a2fd9f7a0feeffc0f629073c594626392a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2684066
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
This reverts commit a9c4b3a749.
Reason for revert: This made ARCVM fail to boot on kukui-arc-r. See http://b/180126126.
Original change's description:
> rutabaga_gfx: cross-domain: a new year's miracle in February
>
> The cross-domain context is specialized for cross domain
> allocation/resource sharing. It takes direct inspiration from
> the pioneering virtio_wl device and tries to incorporate
> similiar functionality into virtio_gpu.
>
> The goal here is just to introduce the building blocks so we
> can continue experimenting. In particular, this change:
>
> * hooked up the RutabagaChannels. This is typically a socket to
> Wayland or Mojo for the camera use case.
>
> * added CROSS_DOMAIN_CMD_INIT and CROSS_DOMAIN_CMD_GET_IMAGE_REQS
> to the cross-domain protocol. Further commands (such as
> CROSS_DOMAIN_SEND) will be needed, but that requires more
> Sommelier refactorings.
>
> * added a path to RutabagaGralloc to allocate via minigbm or shared
> memory.
>
> * Recieves responses via a shared ring buffer of type BLOB_MEM_GUEST.
> The synchronization protocol looks positively primitive compared to
> the revolutionary Address Space Graphics (ASG) algorithm [1], but
> it may be sufficient for the Wayland use case.
>
> [1] https://goto.google.com/address-space-graphics
>
> BUG=b:146066070, b:173630595, b:150239451
> TEST=launch virtual machine with 2D mode
> TEST=launch virtual machine with 3D mode
> TEST=run sommelier with "wl-dmabuf" and "wl-shm"
>
> Change-Id: I46784f17040494ce3a646bdbde516800aa64bd5d
> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2626488
> Tested-by: kokoro <noreply+kokoro@google.com>
> Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
> Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
> Reviewed-by: Zach Reizner <zachr@chromium.org>
Bug: b:146066070
Bug: b:173630595
Bug: b:150239451
Bug: b:180126126
Change-Id: Ie33442fdcedcf43b6a24d25198fa2d88b5b96919
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2695056
Reviewed-by: Ryo Hashimoto <hashimoto@chromium.org>
Reviewed-by: Hiroki Sato <hirokisato@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Hiroki Sato <hirokisato@chromium.org>
Commit-Queue: Hiroki Sato <hirokisato@chromium.org>
Destroying a stream while there are outstanding async commands results
in the responses for those commands having no corresponding tracked
descriptor. Instead of trying to handle this case specifically, make
untracked async responses non-fatal errors, instead of shutting down the
decoder device completely.
BUG=b:177697115
TEST=android.security.cts.StagefrightTest
Change-Id: I142ec9814fd69ddb79ef16140b7b06cd0c9f0123
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2690728
Reviewed-by: Chih-Yu Huang <akahuang@chromium.org>
Tested-by: David Stevens <stevensd@chromium.org>
Commit-Queue: David Stevens <stevensd@chromium.org>
The newly added async primitives allow for increasing the separation of
the various tasks performed by balloon. Breaking each task in to an
asynchronous function.
BUG=chromium:901139
TEST=Boot crosvm, run 'crosvm balloon' to set the balloon size, check
'vmstat' inside the VM to verify the free memory is affected by the
balloon growing and shrinking.
run crosvm balloon_stats command and ensure that stats are reported
correctly.
Change-Id: I0ae2be5eb8e4be65b2eb74de90888357af6ecfd4
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1993163
Tested-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
The cross-domain context is specialized for cross domain
allocation/resource sharing. It takes direct inspiration from
the pioneering virtio_wl device and tries to incorporate
similiar functionality into virtio_gpu.
The goal here is just to introduce the building blocks so we
can continue experimenting. In particular, this change:
* hooked up the RutabagaChannels. This is typically a socket to
Wayland or Mojo for the camera use case.
* added CROSS_DOMAIN_CMD_INIT and CROSS_DOMAIN_CMD_GET_IMAGE_REQS
to the cross-domain protocol. Further commands (such as
CROSS_DOMAIN_SEND) will be needed, but that requires more
Sommelier refactorings.
* added a path to RutabagaGralloc to allocate via minigbm or shared
memory.
* Recieves responses via a shared ring buffer of type BLOB_MEM_GUEST.
The synchronization protocol looks positively primitive compared to
the revolutionary Address Space Graphics (ASG) algorithm [1], but
it may be sufficient for the Wayland use case.
[1] https://goto.google.com/address-space-graphics
BUG=b:146066070, b:173630595, b:150239451
TEST=launch virtual machine with 2D mode
TEST=launch virtual machine with 3D mode
TEST=run sommelier with "wl-dmabuf" and "wl-shm"
Change-Id: I46784f17040494ce3a646bdbde516800aa64bd5d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2626488
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
This was based on an unmerged set of kernel patches that have now been
dropped from the chrome os kernel as well. Remove them here.
BUG=none
TEST=cargo test
Change-Id: Id307bb0b51879033ea82c2d360a57752728fbf3e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2684065
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Allow the caller of config_register_write to determine whether a given
write to PCI configuration space has enabled or disabled the memory or
I/O bits in the command register. This will be used as a signal to
insert or remove a PCI device to/from the corresponding bus.
BUG=b:174705596
TEST=cargo test -p devices
TEST=Manual test with full PCI BAR remapping patch set
Change-Id: I7a3484bd5143d25756c6fdc9f3a8f684db7db8cf
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2388964
Reviewed-by: Tomasz Jeznach <tjeznach@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
This adds support for battery charge, voltage, battery charge counter
in power_monitor and populates these fields from powerd data.
BUG=b:162479956
TEST=Compare voltage_now, charge_full, charge_now/charge_counter,
current_now fields in sysfs on host and in ARCVM
TEST=CTS tests android.cts.statsd.atom.HostAtomTests#testBatteryVoltage,
android.cts.statsd.atom.HostAtomTests#testFullBatteryCapacity
and android.cts.statsd.atom.HostAtomTests#testRemainingBatteryCapacity
pass in ARCVM
Change-Id: I3f93f499fa7d00cc5a0a2b69e7cfbcd233a2983a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2681212
Tested-by: Alex Lau <alexlau@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Alex Lau <alexlau@chromium.org>
Use resources allocator to assign or reserve PCI device address.
For pass-through devices it will enable 1:1 mapping to the host BDF.
Transition to address_allocator for pci address and irq allocations.
BUG=None
TEST=build_test && tast run vm.*
Change-Id: I854da9645a305b7b24acb3dd6d851c3486ed23f7
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2210848
Tested-by: Tomasz Jeznach <tjeznach@chromium.org>
Commit-Queue: Tomasz Jeznach <tjeznach@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Adds the crosvm-side infrastructure to build and test
in kokoro.
There is a build script for testing on x86, aarch64
and a separte script for analysis (clippy, fmt).
These will run in parallel on Kokoro. To test the
scripts locally, a simulate script is provided.
Runtime on my workstation:
- aarch64: 10m
- x86: 2:30m
- analysis: 1:40m
BUG=b:177951955
TEST=./ci/kokoro/simulate_all
Change-Id: I2f666ec768e6c3391a258dc7f0cbd999ad9b2fb1
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2654413
Tested-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
When building without the "audio" feature, an import of virtio::snd in
pci_device failed to compile; wrap it in a feature check to fix this.
This fixes the crosvm fuzzer build.
BUG=chromium:1174254
TEST=cargo build --no-default-features
TEST=build crosvm with amd64-generic asan profile
Change-Id: Iecd549c313d6210ee90e9e405c02a9e7581e1141
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2674260
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Auto-Submit: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Manoj Gupta <manojgupta@chromium.org>
Commit-Queue: Manoj Gupta <manojgupta@chromium.org>
rutabaga_gralloc is a cross-platform, Rust-based buffer
manager.
The rationale for this change is:
1) For the {cross-domain, wayland} context type, we need to
have a good story for the crucial "wl-dmabuf" feature. As
minigbm has been thoroughly tested on ChromeOS and currently
powers the "wl-dmabuf" feature, it only makes sense for us to
have a path to minigbm for the cross-domain prototype. This
will be used by Sommelier.
2) While minigbm allocation works well on Chromebooks, it is
not sufficient for cross-platform purposes. For their Virtual
Graphics Interface (VGI) initiative, Android graphics
virtualization experts have expressed their desire for a Vulkan
based allocator. This will to go alongside cros_gralloc in
minigbm, which is considered by many to be the ""world's
premiere gralloc implementation".
3) Android graphics virtualization experts have expressed their
desire for vkMapMemory(..) to be used when crosvm is in
multi-process mode. Currently, only dma-buf mmap() is supported
for zero-copy blobs in multi-process mode. dma-buf mmap() is not
guaranteed to work on Nvidia (a "must have" for Cuttlefish) or
any other driver for that matter (we *make* it work for ChromeOS).
Possibly only solution: vkMapMemory ;-)
With these goals in mind, here's a summary of the revelant changes:
* Renamed the {gpu_allocator.rs, GpuMemoryAllocator trait} to be
{gralloc.rs, Gralloc trait}.
* Moved all GPU allocation out of the resources crate and into
the rutabaga_gfx crate. This will allow the resources crate to
be focused on managing resources for virtual machines.
* Moved the gpu_buffer crate into the gralloc module in the
rutabaga_gfx crate. The same functionality is now under
"minigbm.rs", "minigbm_bindings.rs" and "rendernode.rs"
* Added an optional dependency on vulkano.rs. vulkano.rs is a safe
Rust wrapper around the Vulkan api [a]. It's emphasis on type
safety makes a good fit for crosvm, though there are other high
quality crates out there (gfx-rs, ash.rs). Though development
has slowed down, it should satisfy goals (2) and (3) quite easily.
* Added a system_gralloc implementation based on memfd. This can be
used when minigbm or Vulkano features are not used, to replicate the
highly useful "wl-shm" feature in Sommelier. Astute observers will
note this can also enable seamless Wayland windowing without GPU
features for Android too. Some minor changes to the base crate were
needed.
* Cut down on the amount of DrmFormats to the subset needed by
Sommelier and cros_gralloc.
* Moved checked arithmetic into it's own file.
* Internally renamed to "wl-dmabuf" feature to be the "minigbm"
feature. This is because "wl-dmabuf" has a dependency on minigbm.
* Small rutabaga_gfx cleanups
[a] https://github.com/vulkano-rs/vulkano/blob/master/DESIGN.md
BUG=b:146066070, b:173630595, b:150239451
TEST=launch virtual machine with 2D mode
TEST=launch virtual machine with 3D mode
TEST=run sommelier with "wl-dmabuf" and "wl-shm"
Change-Id: I693a39cef64cd98e56d843d3c60caa7983d4d6e1
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2626487
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Offset right now means the offset from base address that the
device was accessed at. And address is the absolute address
of the device's access in its address space. The port 0x61 and
0x64 is the absolute port number.
BUG=None
TEST=boot VM and run reboot command
Change-Id: I51ee90e51b559254cf76f2bec4d174294961fe1c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2648858
Reviewed-by: Colin Downs-Razouk <colindr@google.com>
Reviewed-by: Alistair Delva <adelva@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested-by: Alistair Delva <adelva@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
The arcvm guest has been observed to fail early in boot with a low
probability; the root cause seems to be a missing interrupt from the
virtio-block device causing the guest to wait forever for a notification
that does not happen.
In testing, it seems that ignoring the VIRTQ_AVAIL_F_NO_INTERRUPT flag
set by the guest avoids the issue; possibly there is a race in the
publishing of used descriptors versus the checking of this flag, but I
was not able to find a definitive solution.
Ignoring the flag means that we may occasionally trigger an interrupt
when the guest has indicated that one is not necessary; this is, at
worst, a slight performance degradation, not a correctness issue, since
the guest kernel will ignore spurious interrupts.
BUG=b:172975852
TEST=Restart arcvm in a loop without failures 1000+ iterations
Change-Id: I4c91ccc5dadc03dde43008ff20fae1c4592e19da
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2648009
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
These will eventually be used when the virtio-snd device is
implemented as well as by the VioS audio backend.
BUG=b/174713663
Change-Id: Id9fe1527a128df0059805076c01e20ddb1ad2b72
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2574812
Auto-Submit: Jorge Moreira Broche <jemoreira@google.com>
Tested-by: Jorge Moreira Broche <jemoreira@google.com>
Commit-Queue: Jorge Moreira Broche <jemoreira@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
There are a lot of changes in this one but these are the high-level
points:
* Both executors now support non-fd futures and it's now possible to
start a poll operation on one thread and then await the result inside
a UringExecutor on another thread. The reverse doesn't work yet but
will once we make UringContext sync.
* A few layers of indirection have been removed so hopefully both the
implementation and the interface are simpler.
* The thread local magic is gone in favor of directly calling methods on
an executor. Executor handles can be cheaply cloned to make this
easier.
* Heap allocations are limited to the spawn and spawn_local methods so
it's possible to completely avoid heap allocations if callers only use
the run_until method.
* The IoSource, Executor, FutureList traits are gone.
BUG=none
TEST=unit tests
Cq-Depend: chromium:2629068
Change-Id: I86053007929c36da66f3b2499cdefce0b5e9a180
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2571401
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Noah Gold <nkgold@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
The encoder should be able to start encoding when receiving 1 input
buffer. This CL changes the minimum input buffer from 2 to 1.
BUG=b:175745193
TEST=android.mediav2.cts.EncoderProfileLevelTest
Change-Id: I97060d0304cf41369467dc62d12bbae7e54b6b22
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2602299
Tested-by: Chih-Yu Huang <akahuang@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Chih-Yu Huang <akahuang@chromium.org>
The decoder should be able to start decoding when receiving 1 input
buffer. This CL changes the minimum input buffer from 2 to 1.
BUG=b:176266656
TEST=android.media.cts.DecoderTest#testEOSBehaviorVP8
Change-Id: I2b055b145993d35c00a07bc7081db84117e36423
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2602297
Tested-by: Chih-Yu Huang <akahuang@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Chih-Yu Huang <akahuang@chromium.org>
It's possible to compile the gpu device without virgl_renderer.
In fact, in many instances, this may be required.
This builds the gpu device default, but only with --gpu do I see
/dev/dri/renderN128, so this should be safe.
BUG=b:173630595
TEST=compile and run
Cq-Depend: chromium:2592111
Change-Id: I5fbf2de8a2f818a9ca2e5ac4a1a02c7797cff927
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2592089
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Auto-Submit: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Support virtio-fs's DAX (direct memory access) operation which allows the guest
to directly access file pages.
Specifically, FUSE_SETUP_MAPPING and FUSE_REMOVE_MAPPING operations are
supported.
This option can be used by specifing `dax` option when mount a file system in
the guest.
The DAX optoin improved file I/O performance in most cases.
In Fio tests, both of read and write score were improved by 1.3-14x depending on
test cases.
In Blogbench tests, which create many small files, DAX improved the write score
by 1.5x while the read score was reduced to ~25% (20391 -> 4593).
Here is an excerpt of results:
Fio
* seq_read: 10.2x (143528 -> 1464911)
* seq_write: 3.3x (61253 -> 896791)
* rand_read: 11.6x (138753 -> 1612739)
* rand_write: 14.6x (61253 -> 896791)
* surfing_read: 1.3x (98473 -> 127907)
* surfing_write: 1.3x (83309 -> 108089)
Blogbench
* read: 0.23x (20391 -> 4593)
* write: 1.50x (248 -> 373)
BUG=b:147341783
TEST=Run vm.{Blogbench, Fio} with CL:2291856
Change-Id: I4a47c601412ed32d926de6304337e1594252d258
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2108315
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
