This search/replace updates all copyright notices to drop the
"All rights reserved", Use "ChromiumOS" instead of "Chromium OS"
and drops the trailing dots.
This fulfills the request from legal and unifies our notices.
./tools/health-check has been updated to only accept this style.
BUG=b:246579983
TEST=./tools/health-check
Change-Id: I87a80701dc651f1baf4820e5cc42469d7c5f5bf7
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3894243
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Fixes a couple of files that were missing them.
BUG=b:242605601
TEST=./tools/health-check --fix
Change-Id: I620d6a939cb824e014002152584aacfc5dfdf7e8
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3835648
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Add support for creating block devices using the `crosvm devices`
command.
Due to conflicting seccomp policies between vhost-user transport and the
block device, we need to temporarily remove some lines from
vhost_user.policy and vvu.policy and reproduce them in the serial
device's policy. This will be handled properly later using a new seccomp
policy parser.
BUG=b:217480043
TEST=`crosvm devices --block vhost=/tmp/vu-block,path=disk.img` results
in a working vhost-user block device.
TEST=`crosvm devices --block vhost=0000:00:10.0,path=disk.img` results
in a working VVU block device.
TEST=regular virtio block device is usable as jailed root device.
Change-Id: Ide62adbf81390eb39cd10f3d2880e2c065982d05
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3765000
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Tested-by: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Add support for creating serial devices using the `crosvm devices`
command.
BUG=b:217480043
TEST=`crosvm devices --serial hardware=virtio-console,console,stdin,type=stdout,earlycon,vhost=/tmp/vu-serial`
results in a working vhost-user serial device.
TEST=`crosvm devices --serial hardware=virtio-console,console,stdin,type=stdout,earlycon,vhost=0000:00:10.0`
results in a working VVU serial device.
Change-Id: I06fa4c8e27e90fa00c64b38dd25c7e9a91ee77fc
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3762975
Reviewed-by: Morg <morg@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Tested-by: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Add a new `devices` command to start one or several jailed vhost-user
devices.
`devices` improves upon `device` in the following ways:
* Several devices can be created in one command,
* Devices can be configured with the same arguments as the `run` command,
* The created devices are jailed similarly to the `run` command.
This CL does not enable any device to be started yet, it only does the
plumbing to allow it. Follow-up CLs will start adding devices to this
command.
With the following CL, the serial device can be tested as follows:
$ ./crosvm devices --serial hardware=virtio-console,console,stdin,type=stdout,earlycon,vhost=/tmp/vu-serial
The parameters of the `serial` argument are the same as with `crosvm
run`, with the exception that the `vhost` parameter needs to be provided
to inform where the listener should await its front-end connection.
`vhost` can either take a PCI device address, in which case VVU will be
used, or a socket path for regular vhost-user.
Using the example above, a VMM can connect to /tmp/vu-serial and use it
as a console device.
BUG=b:218223240
TEST=./crosvm devices --serial hardware=virtio-console,console,stdin,type=stdout,earlycon,vhost=/tmp/vu-serial
gives us a working vhost-user serial device.
TEST=Same command as above ran inside a VVU device VM with vhost=<PCI address of VVU device>
gives us a working VVU serial device.
Change-Id: I07d17dca2d02bd180b1667810ef92516ee026839
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3762974
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
By default, KSM is disabled by the kernel. This is harmless if KSM
is disabled, and only causes merging if the user manually enabled
the feature on their kernel. If enabled, significant memory saving
can occur, at the cost of CPU cycles and a reduction in privacy.
Bug: 1346340
Change-Id: I838cdda97ea8d335b1953dd6775311958069898c
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3780870
Reviewed-by: David Manouchehri <david@davidmanouchehri.com>
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Initializing gralloc may spawn threads, so it needs to be done after
sandboxing the wl device. Initializing gralloc requires expanding the
wl device's sandbox. Rather than trying to maintain a new dedicated
minijail configuration for wl, reuse the gpu's configuration. This
should be sufficient, since virglrenderer has to open minigbm within the
sandboxed gpu process.
BUG=None
TEST=ARCVM and crostini GUI on volteer, zorc-arc-r, grunt-arc-r
Change-Id: I291fb59c665a8ba65058a6f55dee959c839bb43c
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3787936
Commit-Queue: David Stevens <stevensd@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Tested-by: David Stevens <stevensd@chromium.org>
Switch virtio-wl to the new shared memory APIs.
Using the shared memory APIs requires establishing mappings based on
shm offset rather than raw pfn. This means virtio-wl needs to manage its
shmem address space itself, rather than relying on
VmMemoryDestination::NewAllocation. To maintain compatibility with older
drivers, a feature bit is used to determine whether drivers expect
mappings to be specified by shm offset or by pfn.
BUG=b:201745804
TEST=launch crostini gui app
TEST=crosvm device wl --wayland-sock $XDG_RUNTIME_DIR/wayland-1 --socket /tmp/vhost.sock
TEST=crosvm ... --vhost-user-wl /tmp/vhost.sock ...
Change-Id: Ia559de7107130440c8f81a30aab1f6b061d15118
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3765014
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: David Stevens <stevensd@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: David Stevens <stevensd@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Directly allocate dma-bufs within the virtio-wl process and remove the
VmMemoryRequest::AllocateAndRegisterGpuMemory type. This is preparation
for migrating to the SharedMemoryMapper interface.
BUG=b:201745804
TEST=Launch arcvm, launch gedit w/crostini, launch gedit w/vhost-user-wl
Change-Id: I232f1fd3dfdb8d7ed068c6b3c2ea23f35d0ddabc
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3765012
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Tested-by: David Stevens <stevensd@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: David Stevens <stevensd@chromium.org>
This was missed in the original rseq change.
BUG=b:235172163
BUG=b:235960683
TEST=emerge-hatch crosvm
Fixes: 17c782f1c1 ("seccomp: add rseq to all policy files")
Change-Id: Id78f0e0cd5c22142230abdc0cea6a7f91d492569
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3765348
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Manoj Gupta <manojgupta@chromium.org>
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
This duplicates rseq in all of the policy files and causes the minijail
compiler to fail due to duplicate definitions.
rseq was already added in commit 17c782f1c1 ("seccomp: add rseq to all
policy files").
This reverts commit 1a7a822858.
BUG=b:235960683
TEST=emerge-trogdor crosvm
Change-Id: I9d45897e6815b6cdd5ef376a27563ebc4af06bdd
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3765347
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Auto-Submit: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Manoj Gupta <manojgupta@chromium.org>
Starting with v4.18, the Linux kernel provides the rseq
syscall which is a mechanism for fast userspace task
synchronization.
Starting with v2.35 glibc uses the new syscall, if it
exists, to gain some performance improvements, so we
need to update the policy files to allow it.
Even on older kernels where rseq is not supported,
glibc will still probe for its existence by expecting
an -ENOSYS response.
BUG=b:235960683
TEST=Local builds against glibc 2.35
Change-Id: I704f2fbf2b058c3a4c3269c7441c3a7324012f8a
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3763901
Commit-Queue: Manoj Gupta <manojgupta@chromium.org>
Owners-Override: Dominick Ng <dominickn@google.com>
Reviewed-by: Allen Webb <allenwebb@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Tested-by: Manoj Gupta <manojgupta@chromium.org>
Allow the restartable sequences system call used by glibc 2.35+.
This is an extension of commit 637402a827 ("Add rseq to the seccomp
policy file on aarch64."), which was originally reverted because the
ChromeOS kernel headers did not have the necessary declarations yet.
This depends on the rseq declarations patch to linux-headers:
https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/3749266/
BUG=b:235172163
BUG=b:235960683
TEST=Start crosvm on x86-64 Arch Linux with glibc 2.35
TEST=emerge-hatch crosvm # ensure seccomp policies compile
Reported-By: Peter Collingbourne <pcc@google.com>
Change-Id: I14e3dfd150a7c06bdafc68a88ef3f755eb7bf90c
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3763776
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Peter Collingbourne <pcc@chromium.org>
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
This CL will add "vtpm_proxy" option into the crosvm.
BUG=b:227283268
TEST=Build OK.
TEST=vmc start --vtpm-proxy termina # With crrev.com/c/3697690
Change-Id: I44c81abc1e2f41a80276f4de70e269c07eff901f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3696293
Commit-Queue: Leo Lai <cylai@google.com>
Commit-Queue: Yi Chou <yich@google.com>
Reviewed-by: Chih-Yang Hsia <paulhsia@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
We are going to use separate policy files per device for the following scenarios:
1) Regular in-VMM virtio device,
2) Virtio device over vhost-user,
3) Virtio device over Vvu.
Each of these scenarios require slightly different policies as a jailed
device process needs to allow not only the system calls necessary for
the device to function, but also those required by the virtio transport
in use.
This CL adds a README.md file to the seccomp directory that details the
naming and policy inclusion rules, and updates the serial, xhci and
coiommu policies to follow the naming scheme.
Vhost-user and VVU policy files will be added along with support for
jailing devices when they are in use.
BUG=b:217480043
TEST=serial device works with `crosvm run`.
Change-Id: I6d454aa6e05d00691fe3346e822ed1fc7b24aed8
Signed-off-by: Alexandre Courbot <acourbot@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3706490
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
This commit will fix crosvm crashes when playing audio
with ac97 device and null backend
BUG=b:233960497
TEST=run aplay -Dhw:0,0 -d 3 -f dat /dev/urandom inside a VM
Change-Id: Ic24853f308d92b2e5831d112f432f72f6fedd73c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3670934
Commit-Queue: Norman Bintang <normanbt@chromium.org>
Reviewed-by: Chih-Yang Hsia <paulhsia@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
On Unix, instead of getting random data from `/dev/urandom`, it will get
it from the `rand` platform agnostic crate instead.
OsRng.fill_bytes on unix will make a syscall to getrandom(2) if
available, otherwise it will read from `dev/urandom` after a succesful
poll to `dev/random`. Regardless of which way a random data is
retrieved, if the entropy pool is not intialized, `fill_bytes` will
block until it is intialized. This shouldn't be a problem because it is
a one time cost.
This CL will also upstream the Windows implementation of the rng device.
BUG=b:213149162
TEST=built and presubmits
Change-Id: Ic017f11795f8006e0bf2a04eb0478b3a3d336507
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3657812
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Richard Zhang <rizhang@google.com>
The top part of gpu_common.policy is supposed to match
common_device.policy. In https://crrev.com/c/1993163 we added
io_uring_setup and io_uring_enter to common_device.policy. Even though
there's nothing known to be broken, add these to the gpu_common.policy
to keep things matching.
BUG=None
TEST=kokoro
Change-Id: Ifd4c53c50ec12eb7e1e14f7eb80d2c9b8f0fbe46
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3631411
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Douglas Anderson <dianders@chromium.org>
The top part of gpu_common.policy is supposed to match
common_device.policy, but "prctl" is in this top part and isn't in
common_device.policy. A bit of history:
* prctl used to be in the common_device.policy but was removed in
<https://crrev.com/c/2837307>.
* Even when prctl was in common_device.policy, it had different
arguments than what we allow in gpu_common.policy.
This is a no-op cleanup change.
BUG=None
TEST=None
Change-Id: Ic71c9da3ef9eb24665711d2000416ff9c87d49a1
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3631410
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Douglas Anderson <dianders@chromium.org>
The TPM device was changed to manually include an edited subset of
common_device.policy in commit 25a86d99cc ("tpm: Update tpm device
policy to support libtpm2") because common_device.policy included rules
for open and openat at the time, and the TPM device needed to override
those rules. Now that common_device.policy no longer defines rules for
open and openat, it is safe to include the common policy instead of
duplicating it.
BUG=None
TEST=build with features=tpm and run with --software-tpm
Change-Id: Ia79d63fcf2cd2c5303384f4d0607b3b543406098
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3482029
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
This was already allowed in common_device.policy for arm platforms, and
it can be called via future/async code that is used by many devices. Add
it to x86_64 and aarch64 common policies as well.
BUG=b:220908060
TEST=Start Crostini with virtio-snd on hatch and trogdo
Change-Id: I9bf8f56ebed0cfe6d5e17e45226cac73db3d6d37
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3482026
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Recent builds (starting R100.14501.0.0) crash when attaching a USB
device to the Linux VM due to calling the statx syscall, which was
missing from the seccomp policy. stat was already allowed, so add statx
as well to prevent the crash.
The change is likely due to the upgrade of the Rust toolchain in the
Chrome OS SDK (https://crrev.com/c/3439725), which landed in this build.
This was already allowed on arm/aarch64, so no other changes are
required.
BUG=b:218565401
TEST=Attach USB device to crosvm on hatch
Change-Id: Ia3a383429a839c68b44040f4b99c990a1f1f8e9d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3448188
Reviewed-by: Long Cheng <lgcheng@google.com>
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
LRU unpin policy is an internal unpin policy which is triggered by
a timer. This policy can be used when there is no external balloon
unpin request.
BUG=b:188481989
TEST=Boot a VM with coiommu enabled + pass through devices.
Change-Id: Icb6e19073cb668fa954aec97e02be77f1b8f6a04
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3292937
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Stevens <stevensd@chromium.org>
Coiommu can be enabled through the command line. E.g.
To enable coiommu for a VFIO pass-through device:
--vfio=/sys/bus/pci/devices/0000:00:02.0,iommu=coiommu
BUG=b:188481989
TEST=Boot a VM with a VFIO pass through device w/ coiommu
TEST=Boot a VM with a VFIO pass through device w/o coiommu
Change-Id: Ica6145d7bc6a4c398f0fc10899f8ee24138615c4
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3292934
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: David Stevens <stevensd@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
This change adds a command line parameter for instantiating a VVU proxy
device.
BUG=b:194136484
TEST=Test with sibling VM with Vhost master connecting to a device VM.
Change-Id: I5ff56e6f1ebca5a7078eca3d951ddbfd411d14fc
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3290381
Reviewed-by: Chirantan Ekbote
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Abhishek Bhardwaj <abhishekbh@chromium.org>
The video device needs to redefine the filters for mmap and mprotect,
which the minijail compiler rejects:
compile_file: /usr/share/policy/crosvm/video_device.policy(35): syscall mmap redefined here
compile_file: /usr/share/policy/crosvm/common_device.policy(26): previous definition here
compile_file: /usr/share/policy/crosvm/video_device.policy(36): syscall mprotect redefined here
compile_file: /usr/share/policy/crosvm/common_device.policy(27): previous definition here
compile_filter: compile_file() failed
failed to compile seccomp filter BPF program in '/usr/share/policy/crosvm/video_device.policy'
Prevent this error from happening by inlining the common_device
declarations in video_device and removing the declarations for mmap and
mprotect.
BUG=b:210601086
TEST=Video device can be created when making crosvm use the .policy
files instead of compiled .bpfs.
Change-Id: Ifa7aa84772ae59123cc04e8c9ea845ba6ed7b559
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3341131
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
When "--gpu-render-server path=<path>" is specified, start the render
server shipped with virglrenderer and initialize virglrenderer with
VIRGLRENDERER_MULTI_PROCESS flag.
The flag makes virgl_renderer_context_create_with_flags create proxy
contexts instead of venus contexts. Each proxy context requests the
render server to fork a subprocess and executes GPU commands in the
subprocess.
BUG=b:177267762
TEST=run vk and gl apps on volteer
Change-Id: If5e2dc3353572cadb60b0c25a3e0ad14f633db91
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3283508
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chia-I Wu <olv@google.com>
The panic handler uses getcwd and readlink to print out the executable
name in the backtrace. Allow these for all devices so that panics
actually work instead of crashing the process.
BUG=None
TEST=intentionally panic crosvm on kevin and check /var/log/messages
Change-Id: If64a752a6f0b1f2f6bdd6663ce77078305f38171
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3309201
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
The syscall is used for the file backed memory region used
by the audio device since https://crrev.com/c/3159883
BUG=b:208264646
TEST=CQ
Change-Id: I02c24da6389d60847996a62ee0eab658f9c4f7cf
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3307240
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Tested-by: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
With the new glibc 2.33 roll, we're seeing crashes live relating to
statx (syscall 397). The process that's crashing is pcivirtio-video,
so we suspect video_device.policy is the breaking policy.
Crash report: http://shortn/_4EWpF4q77O
This was very recently fixed in arm (where the original crash occured),
however, it's still missing in the amd64/x86_64 policy file. It's
very feasible we'll see a similar case in the future with this arch.
BUG=b:187795909
TEST=CQ
Change-Id: I7b02ccf02d214590aadc37dc53e00ad34e178a4a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3291890
Auto-Submit: Jordan R Abrahams <ajordanr@google.com>
Commit-Queue: Manoj Gupta <manojgupta@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Manoj Gupta <manojgupta@chromium.org>
Add support for guest fences backed by host sync_files. Rather than
adding a new fence type, fences are implemented as vfds that only
support hup. The host simply waits on the sync_file and sends the guest
a hup when the fence is signaled.
BUG=b:169908659
TEST=Revert ag/15543199, resize ArcCameraFpsTest
Change-Id: I8c79ec9f418b1d71150b5a19f500c5ac7a6c9b02
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3199298
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: David Stevens <stevensd@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
The sched_yield system call is somehow called by the code the rust
compiler generates and not directly by the author's implementation. That
along with the fact that it won't get called on every run makes it very
easy to miss when adding a new device (that happened with virtio-snd).
Since that call is quite harmless (it could be argued minijail shouldn't
even block it in the first place) it makes sense to allow it for all
devices.
BUG=b/201306350
Change-Id: I9895da6c8060ae83053474ed9e4472ea2cd8d3e3
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3248126
Auto-Submit: Jorge Moreira Broche <jemoreira@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Jorge Moreira Broche <jemoreira@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
newfstatat has been added to a few policies for the
two 64bit architectures, but some more require it to
avoid crashes, so add it to all which contain fstat
or statx.
BUG=b:187795909
TEST=CQ
Change-Id: I3cd0f5379b87102caa256503a888c5a1aa4103b6
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3198571
Commit-Queue: Manoj Gupta <manojgupta@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Enable with `--cras-snd`.
Verified:
Basic playback and capture
Missing features:
* Getting chmap/jack/stream info from CRAS. They are hardcoded for now.
* Jack connect/disconnect notifications from CRAS
* Reporting latency bytes to the driver. It is currently hardcoded to 0.
BUG=b:179757101
TEST=`aplay` and `arecord` inside a debian img with a 5.10 kernel built
with virtio snd support. Launched with crosvm on rammus/kukui/hatch
Change-Id: I240000a92418b75b3eb8dcd241ff320214b68739
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2777991
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Woody Chow <woodychow@google.com>
Reviewed-by: Chih-Yang Hsia <paulhsia@chromium.org>
In some places the faccessat and faccessat2 syscalls were
added only for arm64 but starting with glibc 2.33 they are
required on all architectures, so add them to arm and amd64.
BUG=b:187795855
TEST=Local builds; CQ.
Change-Id: Ica4755844fbbd29d31df2967724abe735ab59f7e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3111369
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Manoj Gupta <manojgupta@chromium.org>
Since CL:2999451, libcras is using timerfd features from `cros_async`,
we need to add timerfd operations to the accepted list of
`cras_audio_device`'s seccomp policy files.
BUG=b:179757101
BUG=b:194452080
TEST=tast run ${DUT_IP} arc.Notification.vm
Change-Id: I74b33fa1e304fccc95b7326e04bedc32feff85f1
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3047951
Auto-Submit: Chih-Yang Hsia <paulhsia@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
