As I'm tinkering with the first real benchmark (pgbench), a few
kernel configs are found to be missing to support psql to run in
e2e test guests. Among with previously added but not uprev-ed
KConfig changes, an uprev is prepared.
Initramfs script is also updated to match distribution behavior.
TEST=locally can pass postgres e2e benchmark
BUG=b:257303497
Change-Id: I69b44e3156d3296cbef7fa41804e8b54e4aaf0ab
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4761848
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Zihan Chen <zihanchen@google.com>
No behavior change intended.
The `reset` methods now wait for the task to be dropped, but that
shouldn't make any difference unless the task's future was currently
being poll'd, which I think would imply a multiple threads invoking the
executor (not supported because of spawn_local usage) or recursion (i.e.
`reset` was called from within the task).
Change-Id: I882ac239d6ee331bc66e0477dfab264d5f6827b5
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4771834
Commit-Queue: Frederick Mayle <fmayle@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
We need to skip the first stream context because Stream ID 0 is reserved
by the specification.
This CL fixes indexing bugs to modify correct stream contexts
BUG=None
TEST=`./tools/dev_container ./tools/presubmit`
TEST=Confirmed a UAS device (Samsung PSSD T7) worked on refvm
Change-Id: Ib3571fc460d5ca04e3469815481296191216b4e5
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4763919
Commit-Queue: Ryuichiro Chiba <chibar@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Add a tool to gather and visualize memory data for a running crosvm
instance.
BUG=b:290331222
TEST=Run the tool for ARCVM/Borealis
Change-Id: Iffb3c60dfab6bc9e21979ef3ce367cad0e8b0514
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4712086
Auto-Submit: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
Commit-Queue: Junichi Uekawa <uekawa@chromium.org>
This only has a sensible value when --bios is used; otherwise, we will
still end up with the previous value (0 meaning 64K BIOS ROM).
BUG=None
TEST=dmidecode
Change-Id: Ieef05d739bb6e9236cb90feb9bcaedfa23f67c3b
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4762784
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Zihan Chen <zihanchen@google.com>
Allows adding an optional serial number to the SMBIOS table.
BUG=b:249382713
TEST=crosvm run --smbios serial-number=abcdef ...
Change-Id: I00a00defb6904dbfa8ae38910b887e0a464787e3
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4761847
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Zihan Chen <zihanchen@google.com>
Reviewed-by: Mike Gerow <gerow@google.com>
Move oem_strings into a struct to allow for clearly-named parameters.
This allows overriding the default SMBIOS strings for BIOS and product
information.
BUG=b:282921262
BUG=b:249382713
TEST=cargo test -p x86_64
Change-Id: I5bf40f3c3ee1b675fdcaf427c15e5b0c74549379
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4761846
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Mike Gerow <gerow@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Zihan Chen <zihanchen@google.com>
Previously, dmidecode would complain that the table was one byte too
short. The final table only has a single 00h byte following it, but the
SMBIOS specification requires a double-null terminator (0000h) after
each structure. The other structures already meet this requirement
because they contain strings, which end in 00h; a single extra 00h
terminator byte is required in this case. On the other hand, the
END_OF_TABLE structure does not have any strings, so it needs to add two
00h bytes as a terminator.
Additionally, the end-of-table struct was represented with the
SmbiosSysInfo struct, which is the wrong size; the spec says the length
should be 4 (only including the type, length, and handle fields). Define
a new type to represent the end-of-table structure so the size is
correct.
Old dmidecode output:
> Handle 0x0003, DMI type 127, 27 bytes
> <TRUNCATED>
> Wrong DMI structures length: 104 bytes announced, structures occupy 105 bytes.
New dmidecode output:
> Handle 0x0003, DMI type 127, 4 bytes
> End Of Table
BUG=None
TEST=dmidecode in guest
Change-Id: Ic12487028d3fb4cf70918071744350272b6ccebe
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4761845
Reviewed-by: Mike Gerow <gerow@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Zihan Chen <zihanchen@google.com>
Instead of having to search for it in the codebase, maybe add a reference here.
If there's more CrOS specific stuff, we can split it out to a separate section later.
BUG=None
TEST=read it.
Change-Id: I4e66e69388881a2022eb6852134be534aff5fdcd
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4762724
Commit-Queue: Junichi Uekawa <uekawa@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
This is slightly different than the PCI class code used by QEMU, which
is 0x0100 (mass storage, SCSI controller). We instead use 0x0180 to
indicate a mass storage controller with a non-standardized/vendor
specific programming interface (ref: PCI Code and ID Assignment
Specification).
SCSI isn't really accurate for a virtio-blk device (our implementation
does not accept SCSI commands at all, although there is a pre-virtio-1.0
option for sending them).
The Linux virtio-blk guest driver does not care about the PCI class code
either way (it only matches on the PCI vendor+device ID range assigned
for virtio devices and uses the virtio-specific device type to
distinguish between e.g. virtio-blk and virtio-scsi), so it should be
fine to use the Other/Vendor-specific subclass code.
lspci diff:
-00:04.0 Unclassified device [00ff]: Red Hat, Inc. Virtio block device [1af4:1042] (rev 01)
+00:04.0 Mass storage controller [0180]: Red Hat, Inc. Virtio block device [1af4:1042] (rev 01)
BUG=None
TEST=lspci -vvvnnn # "Mass storage controller" for block devices
Change-Id: I7958dbb1c197fe52afb386ebb9afa9f5107a56cd
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4740712
Reviewed-by: Morg <morg@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Removes the need of casts for API user.
BUG=b:273555494
TEST= compile
Change-Id: I32c545394e67546ea0bd118452bdbd430dd8735d
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4763869
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
At present, the `tools/examples/example_simple` script fails with an
access error when the user is not added to the kvm group.
This commit makes sure the user is added to the kvm group when trying to
run crosvm in running_crosvm/example_simple.md.
Tested on my local environment and checked the script works regardless
of the user being in the kvm group.
BUG=b:294970555
TEST=./tools/presubmit
TEST=./tools/examples/example_simple works regardless of user being in
the kvm group
TEST=shellcheck
Change-Id: I19e42af048774f68c7e0a93afa89a7acd183ba82
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4763917
Reviewed-by: Takaya Saeki <takayas@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Joe Hattori <hattorij@google.com>
The original wording was very short and a bit unclear so I decided to
re-write it a bit. I also add a link to our getting started page and
further references to crosvm's strong points (sandboxing, etc)
BUG=None
Test=mdbook build + verified it looks good
Change-Id: If4a0c62643222336b32f75668ee61689b06cda09
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4753338
Commit-Queue: Morg <morg@google.com>
Auto-Submit: Morg <morg@google.com>
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
This cleans up the activate() signature and avoids the need to pass two
related (Queue, Event) variables everywhere a queue is needed.
No functional change intended.
BUG=None
TEST=tools/dev_container tools/presubmit
Change-Id: I9e5259428b39ad3a677fbb8a0bf574b3f15a7f35
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4738991
Reviewed-by: Frederick Mayle <fmayle@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
cros_workon_make clobbers files and it's difficult to work with. It
seems like the build process clobbering Cargo.toml and a few files at
every build also does not make incremental build work very well. So
instead of suggesting cros_workon_make, suggest emerge and cros
build-packages. It seems to be what people are using.
BUG=None
TEST=read it
Change-Id: Ibc8ad020b73708b75eb752893ca67da1276fcb71
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4759384
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Just random cleanup while browsing.
Change-Id: Idbbddab072abc0de36e03b7fac8fde263e1bcfec
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4753011
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Frederick Mayle <fmayle@google.com>
Instead of printing an info log, bubble up an error.
Also, added the devices debug_label as context to all the errors.
BUG=b:253514925
Change-Id: I95995ef314a783ed340ff3862e0e5b4061f5179a
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4752935
Reviewed-by: Noah Gold <nkgold@google.com>
Reviewed-by: Richard Zhang <rizhang@google.com>
Reviewed-by: Steven Moreland <smoreland@google.com>
Making this a separate function allows the caller to distinguish whether
the backend supports retrieving the number of queues, which will be used
in a following patch.
BUG=b:262291811
TEST=Boot x86_64 Linux from vhost-user block device
Change-Id: I95ade25c877c795c3b2a2e3ffc868d400f742d96
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4113002
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
... as Cuttlefish would like to start setting these.
BUG=b:200592498
TEST=launch Cuttlefish w/ system blob on ARM board with Nvidia
GPU which has VK_EXT_external_memory_host
Change-Id: I0f4e63c4a29138ec6b43e8fafebaba5216147331
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4760404
Commit-Queue: Jason Macnak <natsu@google.com>
Reviewed-by: Idan Raiter <idanr@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
This will allow differentiating between the keymap, which must be
mapped read-only (this is enforced by at least Weston and Sway), with
all the other handles, which are writeable.
Add them the map_info field. Maybe in the future, they can be apart
of the virtio-spec (if we can't rely on the hypervisor only to enfore
the read-only attribute).
TEST=run a Wayland application in a VM with a wlroots host compositor
run gfxstream
Change-Id: Ie381806a5b7c5edf725caece9a4b02a7f5775ea1
Co-authored-by: Idan Raiter <idanr@google.com>
Tested-by: Ryan Neph <ryanneph@google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4584252
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
VAAPI requires one more system call and access to the mesa drivers on
the host.
BUG=b:262824148
TEST=presubmit
Change-Id: I8c382472675d61365167ec2a8a3f1544e35858c4
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4744561
Auto-Submit: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
The close notifier for a client connection to the control
server wasn't being removed from the run_control wait_ctx
when a client disconnected. This caused WFMO to fail with
a bad handle. This CL fixes that issue.
BUG=b:294134741
TEST=verified sending commands to the control server no longer causes
the VM to exit prematurely.
Change-Id: I66e02ada8903d6b24c1513c4800903a7e51b16b2
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4752841
Reviewed-by: Vikram Auradkar <auradkar@google.com>
Commit-Queue: Noah Gold <nkgold@google.com>
