Support for the VIRTIO_BLK_T_GET_ID operation was added to the non-async
block device while the async block device was under development and not
yet merged. Add support for GET_ID to async block to fix the feature
gap.
BUG=chromium:901139
TEST=Launch crosvm with async disk with id
TEST=cat /sys/block/vda/serial
TEST=cargo test -p devices
Change-Id: I329359b9c4dc459ebcf5846ac5307f56192ce02e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2792681
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Hello everyone ..! After 2.5 years of "on the side" inquiries,
I have finally completed my investigations [1] of the udmabuf!!
udmabuf is a kernel driver that turns memfd pages into dmabufs.
The original hope was it would reduce texture upload costs for
virgl, which it did for larger textures [2]. But no measurable
improvements where seen with real games. In addition, a more
advanced "gfx-streaming" model has since come into the horizon[3][4],
which is more performant, conformant, secure and simpler than
virgl. As such, building more on virgl does not seem to be best
option, but that's another story for another day.
Where does that leave udmabuf, then?!? The investigation was
able to turn up two possible use cases:
1) Intel integrated + dGPU PCI-passthrough resource sharing
When the dGPU is passthroughed into the guest, the dGPU's memory
is not available to the host. Ideally, for zero-copy, we would
like to get the render target out of the guest somehow and then
send to the display. Many approaches have been proposed, such
as Vivek Kasireddy's Vdmabuf driver [5]. The current thinking
is virtgpu guest blobs can be exported, and then imported into
the dGPU -- Vivek is looking into this approach right now ..!!
Sommelier or virtgpu KMS can then share the guest blob with the
host. It's a quite complex use case and requires changes to guest
Mesa GBM to get (such as metadata query) to get the right modifier.
Indeed, some would even say you need a virtgpu context type optimized
for sharing across domain boundaries. minigbm already supports this
for Android upstream's Virtual Graphics Interface (VGI) initiative.
2) Guest VRAM dedicated heap created udmabufs
This use case, proposed by automative virtualization expert Dmitry
Sepp [6], is primarily for automotive hypervisors (such COQOS).
It's typically not easy for such hypervisors to get zero-copy via
BLOB_MEM_HOST3D, and these hypervisors have had their homebrew
versions of udmabuf for many years. It's important to upstream the
workarounds that are currently done for such hypervisors. To increase
security and isolation, a guest dedicated heap is preferred over guest
system memory. We might even need dedicated queues, who knows.
crosvm seems like the most likely upstream target due to it's world
class blob support and open-source nature. As such, this CL adds basic
udmabuf capabilites so these use cases can be developed further via
crosvm.
[1] https://www.youtube.com/watch?v=lp6z3s1Gig0
[2] crrev.com/c/1325515
[3] goto.google.com/address-space-graphics
[4] https://drive.google.com/file/d/19K_6M8QUeOn-x7HVYvoNfnuC6G5vkR8f/view
[5] https://lists.freedesktop.org/archives/dri-devel/2021-February/296177.html
[6] https://gitlab.freedesktop.org/virgl/virglrenderer/-/issues/159
BUG=chromium:892806, b:173630595
TEST=Create a bunch of udmabufs from the guest, with the subsequent
patches
Change-Id: Ia8083c0aa065f303f660ec6875ff5fb76f5d7b4f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2786290
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
This is only needed by udmabuf driver, so key it on yet another
feature flag (called "udmabuf").
BUG=chromium:892806, b:173630595
TEST=cargo test
Change-Id: I434a5d1a35d009af0924440df4f72cc7cc9df0e9
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2786288
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
dverkamp@ suggested that crrev.com/c/1157440 contained a
mis-reading of the relevant Wikipedia article.
BUG=chromium:892806, b:173630595
TEST=boot VM with capabilities list of size 207
Change-Id: I4afbe2058b5439bc502be59b8063a4db0fc5a12b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2792041
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Previously we restricted the virtio_input_event/input_event's value
field to u32. In actuality, this field is an i32 in the kernel, and the
negative values are used for relative mice (among other things). This CL
switches the value field to be signed.
BUG=None
TEST=builds (also tested on another branch)
Change-Id: Ia2c43e1a8ee21aa618d97b308369ab49c194cab4
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2770724
Auto-Submit: Noah Gold <nkgold@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
To be truly OS-agnostic, we need an OS-agnostic Rust wrapper over
the OS-specific handle type. SafeDescriptor seems to be the best
option, and I hope it on crates.io in the future.
This converts virtio_gpu/rutabaga to use the SafeDescriptor handle
when practical. minigbm still uses File in some places, since it
needs to SeekFrom(..), but minigbm is a Linux only thing anyways.
BUG=b:173630595
TEST=boot VM in 2D/3D mode
Change-Id: I18d735844d479f52d82d7976bf9b4e383b2e2252
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2779492
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Zach Reizner <zachr@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Michael Hoyle <mikehoyle@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Some judgement calls were made about unnecessary wrapping. Usually they
would get resolved by removing the wrapping or returning a convenient
error, but the ones that returned results for consistency with other
functions were added to the allow list.
The error handling in the usb code had a lot of unit error types which
is now a clippy lint. This was resolved by either removing the result
entirely or returning a convenient error.
The field_reassign_with_default lint is faulty and was added to the list
of supressions. This affected virtio-wayland code.
BUG=b:179277332
TEST=cargo clippy with rustc 1.50+
Change-Id: Ie812cdeaf7c42f4f2b47b1dc87f05a7c87a60f8f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2757510
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Auto-Submit: Zach Reizner <zachr@chromium.org>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
For some PCI device, its MMIO bar size may not be page size aligned.
When setting user memory region for such bar with not aligned size, KVM
will report failure back and failed to map that bar. As current crosvm
can continue run with this failure, the performance will be hurt as each
time when guest is accessing this bar, it will trap to hypervisor.
To resolve this, extend the size to be page size aligned when setting
user memory region in KVM and do DMA map. This should be safe to extend
because the mmap actually rounds up the mmap size to be page aligned.
BUG=None
TEST=boot vm with a passthrough device whose bar has unaligned size
Change-Id: Ic816984ec503edf7f12da4893b78d996ebf93976
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2717448
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
More recent Intel IO-APICs can support more than 24 interrupt
lines. This change enables variable size of IO-APIC lines for
user level IO-APIC emulation code (split-irqchip).
Reported version and supported IO-APIC registes matching ICH10
implementation of IO-APIC device.
BUG=b:181795297
TEST=boot and allocate irq from upper range.
Change-Id: I56480befb39c4c268266f04e4a93105402248772
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2733579
Tested-by: Tomasz Jeznach <tjeznach@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Tomasz Jeznach <tjeznach@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Bug: 181664980
Test: Launch cuttlefish with crosvm, observe switches /dev/input
device with `getevent -lp`.
Test: cargo test
Change-Id: I209b93421bcfcc4ab26efc8981fcd2d680717d59
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2765762
Reviewed-by: Zach Reizner <zachr@chromium.org>
Auto-Submit: Daniel Norman <danielnorman@google.com>
Commit-Queue: Daniel Norman <danielnorman@google.com>
Tested-by: Daniel Norman <danielnorman@google.com>
Indicate that the code block with instructions for running bindgen is
not Rust code to avoid this warning:
warning: could not parse code block as Rust code
BUG=None
TEST=cargo doc --all-features
Change-Id: I38a9d49487dc1da8e41d3fca5dfa1b8bc8ae5e84
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2762064
Reviewed-by: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
To allow for porting to non POSIX platforms, we've brought the
libchromeos::sync module into cros_async (which was the only
consumer).
BUG=b:180978556
TEST=builds
Change-Id: I97256b1dc37124cebc693c035e63d2c5b29e94b1
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2757280
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Noah Gold <nkgold@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
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>
clippy 1.48.0 has a bug in string parsing in doc comments.
https://github.com/rust-lang/rust-clippy/issues/6022
To avoid this issue, update to use double-quotation instead of single-quotation
inside a code block in a doc comment.
Also, this fixes wrong examples of commands there at the same time.
BUG=none
TEST=bin/clippy
Change-Id: I90e5699f6d4e839304f9d4e05e5c7b21467744cd
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2592001
Tested-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
This CL adds support for VIRTIO_VIDEO_CONTROL_FORCE_KEYFRAME to the
crosvm encoder.
BUG=b:161498590,b:174444769
TEST=tast run DUT arc.VideoEncodeAccel.h264_192p_i420_vm
Change-Id: Ibe0c7d2aa7b41c6a0168a7aa312d6996cc22ef23
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2567308
Tested-by: David Staessens <dstaessens@chromium.org>
Commit-Queue: David Staessens <dstaessens@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Currently only H.264 level 1 is reported to the virto encoder when the
supported H.264 levels are queried. This CL expands the list to contain
all levels up to 5.1 which are supported by most devices, as the VEA
interface currently has no way to query the maximum supported H.264
level.
BUG=b:174967472
TEST=android.media.cts.MediaRecorderTest#testProfileAvcBaselineLevel1
Change-Id: I960f9176fa00180da6f71bcdad558da06e8247c1
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2574583
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: David Staessens <dstaessens@chromium.org>
Commit-Queue: David Staessens <dstaessens@chromium.org>
Currently only the framerate requested on the CAPTURE queue is used to
configure the Chrome encoder's framerate. But according to the V4L2
standard setting the framerate on the OUTPUT queue should also set the
framerate on the CAPTURE queue to the same value.
BUG=b:173668157
TEST=android.media.cts.MediaRecorderTest#testProfileAvcBaselineLevel1
Change-Id: I0753d10d73d52ce4f17fd9bc230d4fa2f06a1b30
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2570833
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: David Staessens <dstaessens@chromium.org>
Commit-Queue: David Staessens <dstaessens@chromium.org>
As part of moving from RawFd to RawDescriptor and related types
(https://crrev.com/c/2462330), the USB attach code was modified to
accept a MaybeOwnedDescriptor instead of a MaybeOwnedFd. Since
MaybeOwnedDescriptor::Owned contains a SafeDescriptor instead of a File,
and the usb_util Device::new() constructor requires a File, a conversion
is required. However, the patch mentioned above used as_raw_descriptor
and File::from_raw_descriptor to do this conversion, but this leaves
both the SafeDescriptor and the newly-created File assuming ownership of
the USB fd. When the SafeDescriptor went out of scope, the fd would be
closed, causing the fd in the File to be invalid (meaning the USB device
does not function at all).
This would show up in the crosvm logs like this:
[devices/src/usb/host_backend/utils.rs:61] fail to submit transfer IoctlFailed(2151175434, Error(25))
[devices/src/usb/xhci/xhci_transfer.rs:399] backend is already disconnected
To fix this, use into_raw_descriptor rather than as_raw_descriptor to
transfer ownership out of the SafeDescriptor without closing the fd.
BUG=b:174289633
BUG=chromium:1151144
TEST=Attach USB serial device to Crostini and verify /dev/ttyUSB0 exists
Change-Id: Ia1c5f94f69ca31ab211ab9f63f23141b4e774ef4
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2579884
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Michael Hoyle <mikehoyle@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
This is a chromeos extension to fuse to support the O_TMPFILE flag.
BUG=b:160932094
TEST=Open a file with O_TMPFILE on a virtio-fs mount
Change-Id: I21a6390e919d5949fbd12bb304b20374b9b9172a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2520561
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
rutabaga_gfx is a cross platform, Rust-based, Wayland and
Vulkan-centric Virtual Graphics Interface (VGI).
Apologies for the mega-change, but it was hard to do this piece
by piece.
The rationale for this change is:
1) Android graphics virtualization experts have been proposing
for a VGI for many months (years?). Their goal is to boot
Android anywhere, everywhere.
2) For the {wayland, cross-domain} context type prototype,
it's desirable to create a {wayland, camera} connection at the
appropriate time. Details can be found in the code, though the
RutabagaChannels have yet to be hooked up.
There's a high chance neither effort will work. As such,
rutabaga is just a prototype.
However, even (1) and (2) don't end up working, this
refactor/cleanup by itself makes a ton of sense.
Here's a summary of revelant changes:
* Removed auto-generated {p_defines, p_format, virgl_protocol}.
These files were added for tests when bringing up crosvm-gpu,
and AFAICT these tests are not run. There's actually now a
commit queue for virglrenderer changes and container boot tests
that provides excellent coverage.
* Removed command_buffer.rs. Used only for the previously
mentioned tests. It's quite nice, but couldn't determine the right
place to put it. Maybe data_model? But removed it in the interim.
* Removed {write_from_guest_memory, read_to_volatile}. The same
basic functionality has been moved into {transfer_write,
transfer_read} in Rutabaga.
* Removed VirtioResource, Virtio3DResource, Virtio2DResource,
and VirtioGfxStreamResource in favor of VirtioGpuResource and
RutabagaResource. This leads to less duplication and clearer
separation between external library functions and VMM functions.
* Moved display and hypervisor memory management functions to
virtio_gpu.rs. This is because external components do not interface
with this functionality, and there was a lot of duplication (for example
map/unmap blob).
* Added context management between gfxstream and virglrenderer.
* Added separate gfxstream and virglrenderer flags.
* Clearer naming.
* Added simple implementations for context init and multiple timelines.
These changes have no effect since all Google kernels don't pass the
revelant flags, but are useful for theoretical {wayland, cross-domain}
prototype.
* Unify RESOURCE_CREATE_3D and RESOURCE_CREATE_2D handling.
* Better error handling.
BUG=b:146066070, b:173630595, b:150239451
TEST=launch virtual machine with 2D mode
TEST=launch virtual machine with 3D mode
TEST=boot ARCVM
Change-Id: I240b0c134a3b562cbc65981837a41f6db7767c92
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2522452
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Lingfeng Yang <lfy@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
This CL
- simplifies ac97_bus_master audio thread spawn logic
- makes data ownership more clear for future maintenance
- saves several redundant lock calls
High level design:
ac97_bus_master <=> one AudioThreadInfo for each Ac97Function
<=> start / stop an AudioWorker
Changes in this CL:
- Add AudioWorker which contains the data, logic inside spawn::thread()
and some controls which own by AudioThreadInfo
- Remove `fn audio_thread`.
- Make AudioThreadInfo an audio thread control interface for each
Ac97Function
- `start` consumes an worker and spawn a running thread
- `stop` stops the thread and destroy the worker
- Add is_running support
- Combine several regs.lock() calls to save mutex lock time.
- Add create_audio_worker to create AudioWorker
BUG=b:173364323
TEST=Build and test audio in VMs
Change-Id: Iac8090fac12ac91f50b3e601efb918d79ba089af
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2550480
Commit-Queue: Chih-Yang Hsia <paulhsia@chromium.org>
Tested-by: Chih-Yang Hsia <paulhsia@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Fletcher Woodruff <fletcherw@chromium.org>
Needed by arcvm. Also fix some style issues with the previous ioctl
definitions.
BUG=b:136127632
TEST=Call this ioctl from inside a VM and see that it is passed through
to the host.
Change-Id: Icdeff9e2c5b15237ed49e6814b8147258a50ccab
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2560286
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
These don't work without a kernel change that we never merged. Arcvm
doesn't need these anymore so just drop them.
BUG=b:136127632
TEST=vm.Virtiofs
Change-Id: I427dee41720b0db1d14f4d03c95ff678ec3fd347
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2573709
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Auto-Submit: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
These are causing the clippy pre-upload hook to fail for me.
BUG=none
TEST=bin/clippy
Change-Id: Ifa5b6b008ca1e930ba203034234ce3da56830b11
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2574584
Auto-Submit: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Fixes crosvm's failure to forward the "use_external_blob"
state flag to the host renderer (virglrenderer).
BUG=b:174794821
TEST=Start a crostini VM and run `DISPLAY=:0 glxgears`, verify graphical
output.
Change-Id: I1ef616079664224e7741cea00b9125c5061ea69d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2574669
Tested-by: Ryan Neph <ryanneph@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Ryan Neph <ryanneph@google.com>
The V4L2 standard allows specifying a stride by using the
v4l2_pix_format.bytesperline field when configuring the input format.
This CL makes changes to properly use the stride requested by the
virtio encode device.
BUG=b:173083834,b:173666696
TEST=android.video.cts.VideoEncoderDecoderTest.testAvcOther0Perf0720x0480
Change-Id: Id7d8bb11ef02ee79c70225202471b9a6d21963c5
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2567309
Tested-by: David Staessens <dstaessens@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: David Staessens <dstaessens@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
This CL makes changes so the VIRTIO_VIDEO_BUFFER_FLAG_IFRAME flag is
set and propagated back to the virtio encoder whenever the Chrome
encoder creates a keyframe.
BUG=b:173077927
TEST=tast run DUT arc.PowerCameraRecordingPerf.vm
Change-Id: I4029f3d7b745937e7960abba896c458182cf942e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2567307
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: David Staessens <dstaessens@chromium.org>
Commit-Queue: David Staessens <dstaessens@chromium.org>
This CL makes changes to use the output buffer size requested by the
encoder client. Typically this output buffer size will be overwritten
with what the underlying encoder requests in RequireInputBuffers, but
for correctness we initially store the requested buffer size. Changes
are also made to not set a resolution on the output parameters, as this
should be ignored according to the V4L2 standard.
BUG=b:162804477
TEST=tast run DUT arc.VideoEncodeAccel.h264_1080p_i420_vm
Change-Id: Id0c530271930eebd90e4f7ba00a186ea567ac10c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2519346
Tested-by: David Staessens <dstaessens@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: David Staessens <dstaessens@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
This change adds support for exporting virtio_gpu fences into
virtio_wl.
Without support for sending fences over virtio_wl, ARCVM must wait in
the guest for fences to be signaled before sending the corresponding
buffers to the host compositor. Under normal composition, it is
relatively rare for fences to be unsignaled when they need to be sent
over virtio_wl, although it does still happen at the far tail end. If
ARCVM falls back to client composition, without this change ARCVM needs
to wait on average 5-15ms (depending on how heavyweight the app's
rendering is) for fences to be signaled.
Support for sending fences over virtio_wl allows this extra latency to
be hidden.
BUG=b:136129939
TEST=Run YouTube+Play Store+graphics benchmarks simultaneously
in ARCVM, with and without client composition.
Change-Id: Ic7f57069c4171104c497aee6721c5c93dc6bafa4
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2363512
Tested-by: David Stevens <stevensd@chromium.org>
Commit-Queue: David Stevens <stevensd@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
This CL wires up the powerd D-Bus PowerMonitor implementation to GoldfishBattery.
BUG=b:137890633
TEST=observe updated power data in ARCVM's /sys/class/power_supply after crrev.com/c/2550102
Change-Id: I38c613f13d3f7601435532213c7733558cb5f83f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2560276
Commit-Queue: Alex Lau <alexlau@chromium.org>
Tested-by: Alex Lau <alexlau@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Allow the user to specify a serial number for each virtio block device
using the new id= parameter:
crosvm run --disk disk.img,id=SERIALNO ...
These serial numbers show up in sysfs for each block device, which
allows them to be uniquely identified regardless of the number or order
of block devices added on the crosvm command line. This can be used to
find a specific device by serial number for mounting at boot time.
BUG=b:157687637
BUG=chromium:775781
TEST=crosvm run -r vm_rootfs.img,id=root -p init=/bin/bash vm_kernel
TEST=cat /sys/block/vda/serial # see serial is set to "root"
TEST=cargo test -p devices
Change-Id: I108cdc47c367fb038d6acd55da60f9e1aae59e68
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2225559
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
A prior CL (@81d5adbad7) removed VIRTIO_F_VERSION_1 from the features on
virtio-rng, which causes Linux to skip and not utilize the RNG device.
This CL pipes protected-vm down to virtio-rng & restores the feature.
BUG=none
TEST=cuttlefish launch_cvd
Change-Id: I32d064ec1ac31e0fa622f14ea0f48988d8d6fa49
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2556080
Tested-by: Alistair Delva <adelva@google.com>
Auto-Submit: Alistair Delva <adelva@google.com>
Reviewed-by: Noah Gold <nkgold@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
See crbug.com/1151517 for details on the failure.
See b/173833661 for a longer term fix.
BUG=b:173833661
TEST=None
Change-Id: I82499b72e39ab524584807dcc35c3d0be7ab1bff
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2553215
Auto-Submit: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Derek Basehore <dbasehore@chromium.org>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Allow devices to be added to a Bus without a mutex. If a device
implements BusDeviceSync and is inserted into the Bus via the new
insert_sync function, the Bus will not lock the device before write and
read operations. This feature will allow IrqChip implementations to use
the mmio bus for APIC mmio, and allow each vcpu to write to their
respective APICs simultaneously.
This also changes the BusDevice trait so read and write functions take a
new BusAccessInfo struct. The BusAccessInfo conveys the full address of
the read/write operation, the offset of the address relative to the
device start address, and an id that in practice will hold the vcpu id
for the vcpu thread perforing the read/write.
As a result, inserts into the Bus are no longer distinguished between
full_addr and non full_addr inserts. Instead, each device's BusDevice
implementation must decide whether they use the absolute read/write
address or the relative read/write offset.
BUG=chromium:1077058
TEST=ran build_test
TEST=ran simple debian image
Change-Id: I9125aaa69869c1004b6c6a099b50f5c58038d4ab
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2514662
Reviewed-by: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Colin Downs-Razouk <colindr@google.com>
Add methods to the IrqChip trait to block in userspace on halted vcpus.
Add IrqChip::check_capability, used for cpuid setup.
Move interrupt injection logic from linux.rs to a new
IrqChip::inject_interrupts method, which replaces interrupt_requested
and get_external_interrupt.
These changes are to support setup, run loop, and injection in the
userspace irqchip.
BUG=chromium:1077058
TEST=boots with KVM kernel irqchip, KVM split irqchip
Change-Id: I8f46b5edf36acc485b5f76e7aed3e71c3b984c0e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2419674
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Colin Downs-Razouk <colindr@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
This test exercises the jailing and communication with the forked
process.
The test must be run single-threaded for the
fork to be successful.
BUG=b:171750410
TEST=This is the test
Change-Id: I879dfa46a2d39ee8115ca6b81faf63c930aab3cb
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2503480
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Auto-Submit: Dennis Kempin <denniskempin@google.com>
The write call would write in big endian, but the device should
be using native endian.
BUG=b:171750410
TEST=This bug was caught by the accompanying unit test.
Change-Id: I65aa4c89857766e5ef3280bde90e6ba3a33d1ebd
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2515059
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Drain is cancelled by clearing either of the stream's queues. To work
around a limitation in the VDA api, the output queue is cleared
synchronously without going through VDA. Because of this, a drain
cancellation response from VDA might fail to find the drain's
AsyncCmdTag.
BUG=b:170184723
TEST=android.mediastress.cts.MediaRecorderStressTest#testStressRecordVideoAndPlayback
Change-Id: I1d54c9c4acfa7578addb947e1196313010a8431d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2535964
Reviewed-by: Chih-Yu Huang <akahuang@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: David Stevens <stevensd@chromium.org>
The S5 capability allows the VM to be powered off when user execute
'poweroff' command. This is done by trigger the exit event through
the ACPI PM1 control so that crosvm can shutdown the VM in the end.
BUG=None
TEST=boot a VM and then run 'poweroff' command from VM's shell. The
VM can exit.
Change-Id: Iaad5615fd72550568362090c3b876202055cc25a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2534098
Reviewed-by: Tomasz Jeznach <tjeznach@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
Wrap the code to access various parts of the virtio queue in-memory data
structures into helper functions to clarify the logic of the top-level
Queue functions. Previously, the memory address calculations and guest
memory read/write invocations were mixed together with queue "business
logic" in a way that made it hard to follow and led to duplicated code.
BUG=None
TEST=Boot crostini on eve
TEST=cargo test -p devices
Change-Id: I6e79b9909bde377cd078c75925c62de0234bb21b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2527815
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
This CL transitions most structs to RawDescriptor and the
associated traits if possible.
BUG=b:162363783
TEST=./build_test
Change-Id: Iabae6ac212787836d77de2b9ffb5d451421ab0dd
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2530911
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Michael Hoyle <mikehoyle@google.com>
Commit-Queue: Michael Hoyle <mikehoyle@google.com>
Add a new command "battery" which is used to modify the virtual
battery/ac status.
When there is goldfish battery device model created, the command
is able to sent to the goldfish battery monitoring thread. If no,
the command won't be sent.
The supported commands are:
1. crosvm battery goldfish status <status string> crosvm.sock
2. crosvm battery goldfish health <health string> crosvm.sock
3. crosvm battery goldfish present <number> crosvm.sock
4. crosvm battery goldfish capacity <number> crosvm.sock
5. crosvm battery goldfish aconline <number> crosvm.sock
"goldfish" is the battery identifier to specify which virtual battery
is going to be modified by this command in case there are multiple
virtual batteries in the guest in future. Right now only one goldfish
battery is supported.
BUG=chromium:1050432
BUG=b:137890633
TEST=create VM with parameter "--battery" or "--battery=type=goldfish"
and boot linux guest with goldfish_battery driver enabled. From host
side, execute command "#crosvm battery goldfish status discharging
crosvm.sock" can make the guest receive an interrupt, and the status
sysfs is changed to "Discharging". Also tested the other commands
as well.
TEST=modified values are visible in ARCVM and interrupts are triggered
Change-Id: I82177811a6f2b1960f7895522760ff3b8143163f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2119574
Tested-by: Alex Lau <alexlau@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alex Lau <alexlau@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
The goldfish battery irq will be used to notify the guest driver that
battery/ac status changed. And the status changing will be done through
external crosvm commands. So the irq injection needs to be done in a
seperate thread which can receive these commands.
BUG=chromium:1050432
BUG=b:137890633
TEST=create VM with parameter "--battery" or "--battery=type=goldfish"
and boot linux guest with goldfish_battery driver enabled. The sysfs
created by the goldfish_battery driver have no issue observed.
TEST=goldfish_battery driver is loaded on ARCVM and interrupts are enabled
Change-Id: Icc902dd8c00bdcf6cb271b20d928a4081533dde6
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2119573
Commit-Queue: Alex Lau <alexlau@chromium.org>
Tested-by: Alex Lau <alexlau@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Create goldfish battery device model for guest. Provide the
minimal properties and basic accessing for the golfish_battery
driver in the guest.
BUG=chromium:1050432
BUG=b:137890633
TEST=create VM with parameter "--battery" or "--battery=type=
goldfish" and boot linux guest with goldfish_battery driver
enabled. The goldfish_battery driver is loaded successfully.
The /sys/class/power_supply/battery and
/sys/class/power_supply/ac are created successfully.
TEST=cargo test -p crosvm
TEST=goldfish_battery driver is loaded on ARCVM after crrev.com/c/2519336
Change-Id: Iaafa09e3d7e5664d3db8b7df5295f077ec3f6da9
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2119572
Commit-Queue: Alex Lau <alexlau@chromium.org>
Tested-by: Alex Lau <alexlau@chromium.org>
Reviewed-by: Tomasz Jeznach <tjeznach@chromium.org>
Instead of creating IoSourceExt from AsRawFd implementers, we've
switched to creating from a marker trait `IntoAsync`. This lets us use
other types like RawDescriptor easily with this crate. By using the
marker, we also provide some type safety by requiring consumers of
IoSourceExt to declare that their type is expected to work with async
operations. This way we can provide stronger guarantees that an async
IO trait object will behave in a reasonable way.
This CL also purges the cros_async -> base and io_uring -> base
references, and provides the base types needed to add new async
primitives to base.
BUG=none
TEST=builds
Change-Id: I0b0ce6ca7938b22ae8e8fb4e604439f0292678f2
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2504481
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Noah Gold <nkgold@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
This CL fixes the wrong value being used when configuring a bitrate
using the V4L2_CID_MPEG_VIDEO_BITRATE control. Rather than using the
requested value, the original value was wrongly being used.
BUG=b:162804477
TEST=tast run DUT arc.VideoEncodeAccel.h264_1080p_i420_vm
Change-Id: I1381277c324eff035643b5f65c1e03832085e3f0
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2522772
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: David Staessens <dstaessens@chromium.org>
Commit-Queue: David Staessens <dstaessens@chromium.org>
Reviewed-by: Alex Lau <alexlau@chromium.org>
Along with this rename comes updating all usages to the
appropriate RawDescriptor traits. As per usual it touches
many files, but makes no significant changes.
The only remaining instance of "keep_fds" is to call out to
3p lib adhd.
BUG=b:162363783
TEST=./build_test
Change-Id: I6d292cc6404a9f84ffa5bf1320b6545a28842afa
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2488071
Commit-Queue: Michael Hoyle <mikehoyle@google.com>
Tested-by: Michael Hoyle <mikehoyle@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
