The netlink data end boundary should be actually set by msg_len. The
previous calculation of data_end and its usage was probably confused with
data size.
This bug prevented access to the entire netlink's message data.
BUG=b:197247746
TEST=Build and print the `data` when netlink message arrives.
Change-Id: I601bcfee9132649f48f774e23426281ba1e88fde
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3375544
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
The hdr_len was actually keeping length of the netlink message including
header (nlmsg) which was misleading. Rename it to msg_len which is more
accurate.
BUG=b:197247746
TEST=Build with 'USE=crosvm-direct emerge-${BOARD} crosvm'
Change-Id: Id4adcd038d41960eeeb8bda3623c8b3b129ef9df
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3375543
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
android13-5.10 will use this value to avoid conflicts with any other
flags introduced in upstream Linux before the pKVM ABI is upstreamed.
BUG=b:209794844
TEST=tools/dev_container tools/run_tests
Change-Id: Idee7c095ea5350baf2c38ab9190d4cdb46efbf25
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3372683
Auto-Submit: Andrew Walbran <qwandor@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Commit-Queue: Dmitry Torokhov <dtor@chromium.org>
When sandbox is enabled, forking a process for hotplug device
is failure, the error message is:
Failed to fork jail process: Attempt to call fork() while
multithreaded.
This means minijail couldn't fork a new process for added device
when vm has started, so disable sandbox for hotplug device.
BUG=b:185084350
TEST=Boot a guest and hotplug vfio pci device repeatedly
Change-Id: I2983399f41a44984a113c9846aff93fd978a02b5
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2955581
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Device gets irq_num from system_allocator when device is added, this
irq_num should return to system_allocator when device is hotplug removed.
this commit adds a ReleseOneIrq interface into VmIrqRequest, it release
one gsi into system_allocator. So vfio-pci device could call it at device
close function.
For msi and msix interrupt vectors, they have irq tube already and could
call ReleaseOneIrq easily.
For legacy INTx, the gsi for vfio-pci's INTx is gotten from host, and this
gsi maybe share with other device, so the commit doesn't release this gsi
at vfio-pci device's remove, otherwise the gsi shared device will be broken.
BUG=b:185084350
TEST=Boot a guest and hotplug vfio pci device repeatedly
Change-Id: Ibcca226b4b5b2092b5bc94bef8219eea82979086
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2955580
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
When a hotplug vfio-pci device is attached to a bridge parent, kernel will allocate
mmio from its parent's bridge window, so crosvm doesn't need to allocate it.
But previously mmio_regions is used to track existing bar's address and size, but this
commit doesn't allocate mmio, so the initial bar address in mmio_regions is zero,
so this exception should be handled in bar's reallocation code that address 0 isn't
a valid bar address.
BUG=b:185084350
TEST=Hotplug in and out vfio-pci device in a vm repeatedly
Change-Id: I1a082b02065d42eccf46e24941727edf7b6355a9
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3319707
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
For bridge's memroy and prefetch memory window, current the limit is
smaller than the base, this means pcie rp doesn't support this window,
but OS still allocates 2M memroy window and 2M prefetch memory window
for it, this has two problems:
a. kernel allocates mmio, but crosvm's system allocator doesn't capture
this allocation and crosvm still use system allocator to allocate mmio
for hotplug in device, so it may have conflict between kernel and crosvm.
b. the 2MB window is too small, as the added device behind this bridge
is allocated mmio from this window by kernel, if device required mmio
is large than 2MB, the device couldn't work.
This commit preallocates 8MB memory window and 64MB prefetch memory window
for one pcie rp, and let kernel allocate mmio for its children devices
from this window, kernel also maintains the allocation and free of this
window, crosvm system allocator doesn't care about which device own the
segment of this window.
BUG=b:185084350
TEST=Boot a guest and check pcie rp bridge window's base, limit and size
Change-Id: I566a2d81b458da1d2d5f07b689fa898453586adc
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3319706
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
This is what I do all the time manually, maybe this can be automated.
BUG=None
TEST=run it and observe.
Change-Id: Ia32790ca7dd0b8313ce05dcff28509b8a21d4f76
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3336823
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Junichi Uekawa <uekawa@chromium.org>
Motivation: get rid of required options vs help boilerplate
BUG=n/a
TEST=run_tests
I've also done some binary size testing as well:
Baseline:
text data bss dec hex filename
5050303 264640 1072 5316015 511daf crosvm
StructOpt:
text data bss dec hex filename
5400901 277104 1072 5679077 56a7e5 crosvm
StructOpt, default-features = false
text data bss dec hex filename
5418437 275872 1072 5695381 56e795 crosvm
argh
text data bss dec hex filename
5024287 262648 1072 5288007 50b047 crosvm
Change-Id: I7ebe09e38d3854c4a0e5c8e3a2aecb123652ce1e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3339792
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Anton Romanov <romanton@google.com>
Auto-Submit: Anton Romanov <romanton@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Anton Romanov <romanton@google.com>
Currently the crosvm encoder device only supports single-buffer frames,
yet the encoder requires as many buffers to be submitted as there are
component planes in the frame (e.g. 2 for NV12).
This is incorrect and in effect the encoder ignores all but the first
plane, but nonetheless it expects the number of submitted buffers to be
equal to the number of component planes. This makes it impossible to fix
the issue at the kernel level using http://crrev.com/c/3358090.
Change the expectation about the number of buffers to support both
single-planar and multi-planar submissions. That way we won't break the
encoder while fixing the problem on the guest side.
BUG=b:212214039
TEST=arc.VideoEncodeAccel.h264_192p_i420_vm passes on zork-arc-r.
Change-Id: I62763a9dd754697eaab0bae421604a25b0a2f7d3
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3358440
Reviewed-by: David Staessens <dstaessens@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
https://crrev.com/c/3330204 changed the block fuzzer to depend on
hypervisor but did not add the necessary reference to Cargo.toml. Add it
to fix the fuzzer build.
BUG=None
TEST=Build crosvm ebuild with USE=fuzzer
Fixes: 00f1c9fd46 ("Update to the latest pKVM ABI.")
Change-Id: Ic90c6bdd29f87af1c78093a970056467e9c4c36e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3364963
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
In ARCVM `genfs_contexts`, we have hard-coded rules with device node id for
network and virtio-gpu. In crosvm virtio devices creation, the
device node id is assigned by order, so introducing 2 virtio-snd devices
will shift id to id+2 for those devices created after virtio-snd.
This will break ARCVM-next boot.
Changes:
Move virtio-snd device creation after virtio GPU.
BUG=b:213249578, b:199001477
TEST=cargo build
Change-Id: I2fd6ee2c892ae65b0e41d7f42613714a31d7833f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3366166
Auto-Submit: Chih-Yang Hsia <paulhsia@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
This fixes a bug introduced by [1] when removing vfio device and
'device_num' is zero.
A panic occured when unplug a vfio device:
[ERROR:src/panic_hook.rs:90] thread 'crosvm_vcpu4' panicked at 'attempt to subtract with overflow', devices/src/vfio.rs:462:9
The variable group.device_num is 0 when subtract. And when initalizes a
vfio device from hot-plugging workflow, 'group.add_device_num()' is
missing.
BUG=b:185084350
TEST=hotplug in and out a vfio-pci device in guest repeatedly
[1]: 7b80554473
Change-Id: I9a039cd15e9f9414a4a0501c64da13be76e59c1b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3365212
Reviewed-by: Xiong Y Zhang <xiong.y.zhang@intel.corp-partner.google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
This is useful mostly for development and testing.
BUG=b:209795495
Change-Id: Ie8c4dfade2cbc770daa7d97e22b1574fdf895a19
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3330210
Reviewed-by: Will Deacon <willdeacon@google.com>
Reviewed-by: Chirantan Ekbote
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
This involves two main changes:
* Protected VMs must be created with KVM_VM_TYPE_ARM_PROTECTED.
* pVM firmware is now loaded by IPA rather than memslot ID.
There are also a lot of trivial changes because the ProtectionType enum
was moved from the devices crate to the hypervisor crate.
BUG=b:209794844
TEST=Will tested manually with patched kernel and dummy firmware
Change-Id: I1dd75e20063ca4736f155292ca5f70b94664fdd9
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3330204
Auto-Submit: Andrew Walbran <qwandor@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Since users of `DeviceRequestHandler` don't match on `HandlerError`
enum, there are no advantages on using thiserror. So let's switch to
anyhow.
BUG=none
TEST=cargo test
Change-Id: I6d4697e174a4e587c52ec71ef99b453e1d00cc35
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3353058
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Auto-Submit: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Add utilities to bind a vfio-pci device, which will be used in
the virtio-vhost-user driver.
This works like the following use of DPDK's devbind script [1].
$ dpdk-devbind -b vfio-pci 'Bus:Slot.Func'
[1]: https://doc.dpdk.org/guides/tools/devbind.html
BUG=b:194137301
TEST=cargo test in devices
Change-Id: I67fb34ae2ad55320231751ea553a2094bb8cdde4
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3295303
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Abhishek Bhardwaj <abhishekbh@chromium.org>
Auto-Submit: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
pkg_config has introduced a new error type, Error::ProbeFailure, with
version 0.3.23 and returns this new error for the pattern we were trying
to match using Error::Failure. This causes the build script to fail if
the host is using version 0.3.23 or later.
Chrome OS is still using an older version, but trying to build with
cargo is likely to pull a newer one. The pkg_config crate explicitly
advises against matching these errors anyway, so change the strategy by
ignoring the errors if the chromeos feature is not set. That way we
still get clippy coverage while making sure a missing libvda package is
caught during builds that actually use it (libvda is not used outside of
Chrome OS).
BUG=None
TEST=cargo build --features "video-decoder,libvda"
TEST=emerge-zork-arc-r chromeos-base/crosvm
Change-Id: Ib2aad9f41541d3f4fe3cfb89f8b0f857d8033dcb
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3347307
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Add a `Descriptor` type that allows callers to asynchronously wait for
the descriptor to become readable or writable. This is meant to be a
temporary solution so that we slowly convert code over to async rather
than having to do it all at once.
BUG=b:195468578
TEST=unit tests
Change-Id: Ib3ccefe09c25e222afe872d4e6d076e1e3b57b39
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3329741
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
The commit broke the chromeos build. The fix forward is easy, it's
just a typo and a reminder we really need to get libvda code compiling
in Kokoro.
BUG=b:210749428
TEST=emerge-amd64-generic crosvm
Change-Id: I47e0c0b8f843e8b66c00513221b58c6197fe644b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3352172
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Tested-by: Dennis Kempin <denniskempin@google.com>
This passes Cq-Depend lines through to the merge commit.
Right now this is done manually by the oncaller, which then
requires another person to CR+2, slowing down the process.
BUG=b:210863861
TEST=./tools/chromeos/create_merge
Change-Id: I4adacef8b5fb39aa3a300b56fec5ed0ed79980f1
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3342734
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Tested-by: Dennis Kempin <denniskempin@google.com>
Make the decoder able to switch the resource type of its queues when the
new S_PARAMS_EXT command is used.
BUG=b:193202566
TEST=Youtube can play videos on Hatch.
Change-Id: I1ff3c15ae1924c2fdf1b99af9ea24716f17c864f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3340692
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Originally the resource type of both the input and output queue needs to
be provided when the stream is created.
This however does not work well with guest drivers that allow to change
the memory type being used for buffers after the stream is created, e.g.
V4L2.
To mitigate this, allow to specify the resource type as part of the
stream parameters by introducing new GET_PARAMS_EXT and SET_PARAMS_EXT
that work exactly like the original ones, but handle the resource type
in addition. The old commands are still supported to preserve
compatiblity with guests relying on the old commands.
BUG=b:193202566
TEST=Youtube can decode videos on Hatch.
Change-Id: I84277f8b82773a1d8f4f99bb5050345320807cad
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3143583
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
This is a more accurate name since the object does not initially come
from the guest.
BUG=b:161774071
BUG=b:209523781
TEST="emerge-hatch chromeos-base/crosvm" passes.
Change-Id: I618419dc7cfb7203669a5c72b015d5acea50ff24
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3340693
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
This CL adds support for the new GAVD backend that connects directly to
a Chrome media::VideoDecoder through the new mojo::VideoDecoder
interface. The mojo::VideoDecodeAccelerator interface currently used by
the GAVDA libvda backend is deprecated and will be removed in the
future.
To enable the libvda GAVD backend the "--video-decoder=libvda-vd"
argument needs to be provided to crosvm.
BUG=b:189278506
TEST=arc.VideoDecodeAccel.h264_vm
Change-Id: I8383bbc1e4371093bde7b0385efc51752c7bc466
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3026654
Auto-Submit: David Staessens <dstaessens@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
`create_video_device` currently fails if `/usr/lib64` does not exist on
the host, because it cannot be bound to the jail in that case. This
should not be a fatal error as this directory is only needed for AMD
devices and may not exist on all hosts.
In case this directory does not exist on the host, the video device
process will just exit with an obscure error code as minijail's
`process_mounts_or_die` cannot mount it. Logging is not visible to the
user for some reason, so this makes it a pretty difficult issue to
debug.
Fix this by extracting the code that mounts existing directories in
`gpu_jail` and using it from `create_gpu_device` as well.
BUG=b:210599385
TEST=crosvm can start with `--video-decoder` on a host where
`/usr/lib64` does not exist.
Change-Id: Iacdfe6d3925689ba645c07d6cdbcbab5e1729b5c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3341133
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Calling CString::into_raw, changing the length of the string, then
passing it to CString::from_raw is not allowed:
https://doc.rust-lang.org/std/ffi/struct.CString.html#method.into_raw
This uses a vector instead, and truncates it to the length reported by
vsnprintf.
BUG=b:209867862
TEST=Borealis boots, and accelerated graphics work.
Change-Id: I4b08eabda74086819b3fb437247a5f2ef962defe
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3324614
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Phillip Pearson <philpearson@google.com>
The memory type of resources is a per-queue property, so move it here.
On top of making sense, this will also allow us to extend the
virtio-video protocol to support changing the resource type as part of
the parameters, which is something we need to do in order to support
both guest memory and virtio objects as resources.
BUG=b:193202566
TEST=Youtube can decode videos on Hatch.
Change-Id: I4315292a33d4f145d815fef44803881002d59c3b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3340691
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
It's ChromeOS specific and we just added a separate file for that.
BUG=None
TEST=None
Change-Id: I67e77c3d30e4e4bf456677a13130563c57a87464
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3336216
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Junichi Uekawa <uekawa@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>
At present, host-cpu-topology won't set HT flag for vCPU.
It's reasonable to allow Guest have the same HT flag setting as Host
when set host-cpu-topology.
BUG=None
TEST=cargo build
TEST=set host-cpu-topology and check ht flag in /proc/cpuinfo
Change-Id: I116e49975ab32d37c733690bc0f0f96148fbd4f6
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3314869
Reviewed-by: David Stevens <stevensd@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
At present, if no_smt is set, the cpus of Guest still has the HT flag.
To fix this issue, won't set HT flag in Guest's CPUID if no_smt is set.
BUG=None
TEST=cargo build
TEST=set no_smt and check if there's HT flag in /proc/cpuinfo
Change-Id: I8a986867f272face39253b523462dc8a26ab479c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3314868
Reviewed-by: David Stevens <stevensd@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Mattias Nissler <mnissler@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
At present, when set host-cpu-topology option, the Guest still can't
get the hybrid information.
Now, for ADL, the hybrid related info is needed. These info include the
hybrid part flag (bit 15) in leaf 7 of CPUID, the core type and native
model id in leaf 1A of CPUID.
BUG=None
TEST=cargo build
TEST=Check the CPUID dump of Guest and Host
Change-Id: Icc03bc50160fdffc221e992d90225e7ed8081e8d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3314867
Reviewed-by: David Stevens <stevensd@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Fix the error check in the poll_transfers() loop so that ioctl errors
other than EAGAIN are propagated to the caller.
BUG=chromium:1278424
TEST=Connect USB device to Crostini
Change-Id: I5508550011101a98e4d32099ac0044a3d9137018
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3335303
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
When a file descriptor is returned from the poll context that has the
hungup flag set, it should no longer be polled. Remove it from both the
poll context and the map of handlers when hangup occurs.
Additionally, instead of stopping the whole event loop when an event
handler error occurs, just remove the failing event handler from the
watched set and continue. This should improve robustness of the USB
controller emulation.
BUG=chromium:1278424
TEST=Share USB device with Crostini via vmc, then physically unplug
Change-Id: Iccaae0ea24b43d0b5e593ca2fe4418eb3892300a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3335302
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Previously, if any event handler in the event loop failed, it would
print a generic "event loop stopping due to handle event error" message
and stop working. This is not particularly useful for determining which
event handler actually failed. Instead of returning an empty Err, use
anyhow::Context to associate each potential failure with a
human-readable error string.
chromium:1278424
TEST=Cause USB event loop failure, observe more useful message
Change-Id: I438a96bf757946efbd03a99ef0e17dfbf0d4e1c8
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3339793
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Improvements:
- Once a {playback, capture} stream is initiated.
We should start write (read) audio in each callback period or
the underlaying audio server will underrun (overrun).
(Even in the WorkerStatus::Pause state).
- Change the polling loop logic to
wait for next buffer
-> check status
-> try_next desc_chain or exit
-> transfer data or exit
And make start_pcm_worker act like real audio hw device, which
consumes data in every fixed period.
- Right before leaving from WorkerStatus::Quit, we still need to
transfer data to/from the running stream to prevent
underrun or overrun.
Changes:
- changes in start_pcm_worker:
- extract read_data, write_data utils
- implement From<Result<()>, Error> for virtio_snd_pcm_status
- poll next_{capture, playback}_buffer
- if status == WorkerStatus::Pause, still need to transfer data to
prevent underrun or overrun
- split Output and Input stream logic
- use copy_from or copy_to instead to io::copy
- remove Condvar usage
- changes in audio_streams
- add copy_from in AudioBuffer and AsyncPlaybackBuffer
- add copy_to in AudioBuffer and AsyncCaptureBuffer
BUG=b:210197743
TEST=alsa_conformance_test and make sure there is no
`ERR cras_server[1818]: Error reading msg from client: rc: -104` or
`ERR cras_server[1818]: fetch err: -32 for 6490001`
errors.
Change-Id: I004969040881cb2d46b54589e3e7e634ea67d152
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3341135
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chih-Yang Hsia <paulhsia@chromium.org>
