Currently we have two ways to enable networking on crosvm:
1) Pass all 3 of `--host_ip`, `--netmask` and `--mac` to have crosvm
create and configure a TAP device. This requires crosvm to either be run
as root, or to have the CAP_NET_ADMIN capability,
2) Have another process with the above privileges create and configure
the TAP device before exec'ing crosvm with the TAP FD still open and
passing it to crosvm with the `--tap-fd` argument.
None of these ways are very convenient for development as they either
require to get some privilege every time crosvm is invoked, or to use
another program (not distributed with crosvm) to do the setup.
This patch adds the `tap-name` command-line option which allows to
create a network device from a configured persistent TAP interface,
which doesn't require any kind of privilege.
A persistent TAP interface can be configured on the host as follows:
# ip tuntap add mode tap user $USER vnet_hdr crosvm_tap
# ip addr add 10.0.2.1/24 dev crosvm_tap
# ip link set crosvm_tap up
Then after this one-time setup, $USER will be able to use the
`crosvm_tap` interface by simply passing `--tap-name crosvm_tap` to
crosvm, without any extra option or tool.
This is convenient for development setups as one just needs to
permanently configure the TAP interface using standard Linux tools on
the host once.
BUG=None
TEST=Check that networking works after passing `--tap-name` to crosvm.
Change-Id: Id053a97d69e47a6fefdbe7f3134841d2bfa1757b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3325827
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@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>
When the flag is set, virglrenderer can use the get_server_fd callback
to get the socket to the render server.
BUG=b:177267762
TEST=run vk and gl apps on volteer
Change-Id: I692b5068a04e841b0a0ed2344a77908e720e19eb
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3283506
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chia-I Wu <olv@google.com>
Since Android needs separated PCM devices for different use
cases, we add multiple PCM streams support in virtio-snd
for both input and output direction.
Changes:
- Add num_{output, input}_streams support in ChromeOS's backend
- Remove todos since hardcoded_snd_data and
hardcoded_virtio_snd_config are used in cras_backend
implementation only.
- Update help message
BUG=b:199001477
TEST=`cargo test` for Parameters parsing
TEST=`crosvm run --cras-snd=num_output_streams=<num> ...`
and check with `aplay -l`
TEST=`crosvm run --cras-snd=num_input_streams=<num> ...`
and check with `arecord -l`
Change-Id: I59b2fd547b101d099f837f85c0b739f720795990
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3322796
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Woody Chow <woodychow@google.com>
Commit-Queue: Chih-Yang Hsia <paulhsia@chromium.org>
Intel acpi method reads PCIEBAR Base Address Register in host bridge to
get the pcie config mmio base address. This commit emulates this
register, so the acpi method could get the right information.
BUG=b:197877871
TEST=Verify this regsiter's value in a vm
Change-Id: I93bf8e678acc0e085b102a2eb3a88cbf466aed78
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3305944
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Junichi Uekawa <uekawa@chromium.org>
Since PciRoot has been modified into Arc<Mutex<>>, RunnableLinuxVm->root_config
could be changed from PciConfigArch to PciRoot also, this could simplify code
and reduce two functions from PciConfigArch.
BUG=b:197877871
TEST=tools/presubmit
Change-Id: Ibc18587900d6f8259ac1d6f8fe7b3ea4fedad07e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3305942
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Junichi Uekawa <uekawa@chromium.org>
Allow having a Master struct with a backend other than socket. This will
be helpful for multi-platform support.
BUG=b:194137301
TEST=cargo test --all-features in vmm_vhost
Change-Id: Ie1bd8949ddb708c87a964544c6ae2fe7391b1fb5
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3320904
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Expose connection::{socket, vfio} modules so that we don't need to have
prefix for structs there.
e.g. SocketEndpoint -> connection::socket::Endpoint
BUG=b:194137301
TEST=cargo test --all-features in vmm_vhost
TEST=cargo check in crosvm
Change-Id: I7d992a0df5a838fa6a726f366e9595b20405ec3b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3317324
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
This will allow guest OS to issue reset requests via ACPI methods.
BUG=b:3169569
TEST=Build and boot.
Change-Id: I6d29422f962c21a2e513cb4da78515e31468a1e5
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3316834
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dmitry Torokhov <dtor@chromium.org>
This is a bit of a hack, but crosvm does not support overlapping IO/MMIO
regions, so we have to handle reset register in PciConfigIo handler
(which covers 0xcf8 - 0xcff range) instead of installing a dedicated
reset handler separate from PCI root handler.
BUG=b:3169569
TEST=Try rebooting Manatee booted with "reboot=p"
Change-Id: I79991f456d4aaaab2c904e312996208aa72ab6ec
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3316833
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dmitry Torokhov <dtor@chromium.org>
Reserved 64MB mmio space for pcie enhanced configuration access,
and added it into mmio_bus with PciConfigMmio.
Now pci_root will be added into PciConfigIo and PciConfigMmio, so
Arc<Mux<pci_root>> is used.
BUG=b:197877871
TEST=tools/presubmit
Change-Id: Ic90a4cc3dfb00b09358478e129cc8a16e91012c6
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3305941
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
Commit-Queue: Junichi Uekawa <uekawa@chromium.org>
Used to use an unnamed tuple there but instead use the BusRange because
it's semantic and now there's less copying.
BUG=b:188011323
TEST=cargo test --features=direct
Change-Id: I4a10251c758d330b8938090fb5971badcb9b7bdf
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3319716
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Junichi Uekawa <uekawa@chromium.org>
Since ioctl_with_val takes c_ulong, whose size is 64-bit in x86 but
32-bit in ARM, we must not assume it can be converted to u64.
BUG=none
TEST=cargo check
Change-Id: Ib0060bbbe2e06c94bf8802c8e775c808c07ff6a6
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3320123
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Auto-Submit: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Since VIRTIO_SND_R_PCM_PREPARE -> VIRTIO_SND_R_PCM_PREPARE is a valid
transition, we need to release the worker if it's already in
VIRTIO_SND_R_PCM_PREPARE state. Or we could trigger
```
Error in handling tx queue: Error in mpsc: send failed because receiver is gone
```
in handle_pcm_queue while sending `desc_chain` to start_pcm_worker
through the `stream_info.sender()`.
BUG=b:202368198
TEST=Run alsa_conformance_test multiple times
Change-Id: I5f8ee370832ee162fdef71d396dfe848d88af7e1
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3317328
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chih-Yang Hsia <paulhsia@chromium.org>
Reviewed-by: Woody Chow <woodychow@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
While running alsa_conformance_test against the virtio-snd device, the
driver will randomly stop getting irq events forever. (vp_interrupt will
never get called).
At the same time, the host device will still see an uncleared
`interrupt_status` so the `trigger_interrupt` -> `signal`
will just drop the interrupt signal on
the host device side. And the device can't be used forever when the
issue happens.
Root cause:
Irq resample events never get handled in the virtio-snd device, so the
interrupt handler in guest just can't get notified if there are some
unhanded interrupts in the irq line during the resample event.
Changes:
- Add `f_resample` future in the run_worker
- Use `select!` from futures crate with `async-await` feature
- Change local interrupt in run_worker to Rc<RefCell<interrupt>>
- Use anyhow::Context for errors
BUG=b:202368198
TEST=vm.AudioAlsaConformance.virtio_cras_snd
TEST=Run alsa_conformance_test multiple times in guest VM
Change-Id: Id1440420dcfeccbbb455b1d342863e430ef4b6f9
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3317327
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chih-Yang Hsia <paulhsia@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
In pcie enhanced configuration access, register bit number is 12, in order to
support such PciConfigAddress, this commit make register bit number
variable, it could be 8 or 12 decided by caller.
BUG=b:197877871
TEST=tools/presubmit
Change-Id: I96a317896b9536742534bee86f0e8f1acc323292
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3305940
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
The current `VfioDevice::new()` definition is assuming that it's a VFIO
passthrough device that takes a VM guest. To reuse the `VfioDevice` for
cases other than passthrough, this CL rename that method to
`VfioDevice::passthrough()` and adds a simpler constructor.
BUG=b:194137301
TEST=build
Change-Id: I2bd420b17ed8675c1630c8fc41f47485351d8bb0
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3149874
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
This change implements read and write for notifications region in the
bar.
BUG=b:194136484
TEST=lspci in the guest and look for the proxy device.
Change-Id: I06a98e5cbabc01d8799a033cd1ad916d14de1644
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3288868
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Abhishek Bhardwaj <abhishekbh@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Pci spec defines Interrupt Pin register that devices don't use an interrupt pin
must put a 0 in this register. The values 05h throgh FFh are reserved. So if
vfio-pci reads interrupt pin register and gets value like 0, 0x5~0xFF, it means
vfio pci device doesn't support legacy intx, then interrupt_evt and
interrupt_resample_evt don't need to be saved, finnaly enable_intx ioctl won't
be called into kernel vfio.
This fixes an error message during CrOS reboot, poweroff, xhci controller's
suspend and resume on Brya ManaTEE:
ERROR: vfio 0000:00:0d.0 device Intx enable failed: failed to enable vfio device's
irq: Invalid argument (os error 22).
BUG=None
TEST=check vfio-pci xhci controller (00:0d.0)'s function during suspend and resume.
Change-Id: Ib25c8877f0e10431c097914aa5cc7b7ad0e24612
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3312579
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
This change allocates the additional resource bar for the VVU proxy
device and adds read / write stubs for the notification region.
BUG=b:194136484
TEST=Compile.
Change-Id: Ia7b0e522462aea68fb6ccf11037320393cc4ffd5
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3288866
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Abhishek Bhardwaj <abhishekbh@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
This change separates the number of queues of the proxy device from the
number of queues of the actual VVU device. It also fixes the device type
constant to the number specified by the spec. Also, change PciClassCode
for legacy devices. The guest VFIO driver code doesn't enumerate the
proxy device without it.
BUG=b:194136484
TEST=Compile.
Change-Id: I105a46168302b1cc53a7c61c55019d8b1e703b40
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3288865
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Abhishek Bhardwaj <abhishekbh@chromium.org>
Update handle_irq_resample() to resemble the previously-removed async
block version, which clones the resample event in a separate block so
that the Rc<RefCell<...>> is not borrowed across await. Otherwise, other
users of the Rc<RefCell<Interrupt>> cannot borrow it mutably.
BUG=b:208264646
TEST=tools/presubmit
TEST=Boot Crostini on hatch
Change-Id: I2505d580ae7813b20fff60e7ced0e4f706339a81
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3311457
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
If a resource bridge becomes closed for some reason, it will always get
signaled as ready and will make the poll call return immediately, only
to make us handle an error and go back to the same loop indefinitely.
This results in lots of error messages in the host's log and one CPU
core very busy doing nothing.
Fix this by making `process_resource_bridge()` return a `Result` and
removing the faulty bridge when it returns an error.
BUG=b:161774071
TEST=Make the video process exit after establishing the bridge, notice
that the bridge is properly removed on the GPU process side and the
latter does not flood the host's logs with the same error.
Change-Id: I19767d779a44caccf0870faf422c7234c4232818
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3310341
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
For the crosvm externalization project, we want to be able to compile
video support without libvda, which is only supported on Chrome OS.
Add an explicit "libvda" feature to crosvm and make all the libvda code
depend on that feature, so any trace of libvda can effectively be
compiled out.
For compatibility, the "libvda" feature is selected by the
"video-decoder" or "video-encoder" features.
BUG=b:161774071
BUG=b:169295147
TEST=`cargo build --features="video-decoder,video-encoder"` results in a
crosvm binary with libvda enabled.
Change-Id: Ice3d3089b73b77f6b009400953063f2cf8f385da
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3026351
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
The virtio-console device implementation was losing track of the host
input stream when it reset. This change only creates the read thread
once and reuses it for all worker threads.
Test: Run with a virtio-console device that resets
Bug: b/208540565
Change-Id: I6abcd35a7e7664f2bbdc0d977c2eacad49e50378
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3309208
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Commit-Queue: Cody Schuffelen <schuffelen@google.com>
The previous implementation would lose track of the host output
io::Write stream on receiving a virtio reset request, due to how the
output instance was being passed around through Option instances.
This change replaces one level of Option state with a reference instead,
so the Console instance retains ownership over the output instance and
the virtio-console Worker instance only holds a mutable reference.
Test: Run with a virtio-console device that receives a virtio reset
Bug: b/208540565
Change-Id: Ib672ac244a7209797e1d64feca913b12f31a66d0
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3309207
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Cody Schuffelen <schuffelen@google.com>
- F_CONTEXT_INIT is in Linux 5.16 now
- F_RESOURCE_SYNC should come before other features now.
BUG=b:208516032
TEST=compile
Change-Id: I8dfed584b544d6140ba80c2d474dedfcb679417e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3309197
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Auto-Submit: Gurchetan Singh <gurchetansingh@chromium.org>
Intel SSD 660P Series NVME block device has an overlapping msix
table and msix pba table as the following information shows.
ab:00.0 Non-Volatile memory controller: Intel Corporation SSD 660P Series (rev 03)
Capabilities: [b0] MSI-X: Enable- Count=22 Masked-
Vector table: BAR=0 offset=00002000
PBA: BAR=0 offset=00002100
In curruent add_bar_mmap_msix function, these two table would occupy
the same page. So when add_bar_mmap_msix trys to find the msix table
corresponding pages for the second time, it fails to find the page and
lead to the entire mmaps are cleared and return null mmaps. Thus, there
is no real memory region are mmaped and lead to quite low I/O performance
for this pass-through NVME disk.
BUG=None
TEST=Unit test
TEST=pass-through the 660P SSD into guest and run FIO read/write test,
the throught increases to ~500MBps form ~20MBps.
Change-Id: I1571e694b0a1f01a738650b361eaef93554a8c55
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3213315
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Virtio-iommu might be created without any endpoints. In this case, we
need to assume a default page_size_mask default value. 4K is a
reasonable value to devices.
BUG=b:185084350
TEST=Boot a guest with a pass-through device which has the "iommu=on"
Change-Id: I29344f8ef52e3358198dd5a917083244310ffaaa
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3297406
Reviewed-by: David Stevens <stevensd@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Pass-through PCI devices don't need vfio to do the iova mapping for
their bars' memory, because when accessing their bars' memory,
pass-through PCI devices' DMA requests don't travel to RC. Therefore,
keeping the mapping relationship is useless.
BUG=b:185084350
TEST=Boot a guest with a pass-through device
Change-Id: I7944183553518437d03bdfcfebf3790268bbd9e4
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3284012
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>
Since vhost_user is the only module in vmm_vhost now, remove this module
and have everything in the top-level module.
BUG=b:206900656
TEST=cargo check
Change-Id: I6663a93654e5d692efc7d9904fff0d207144c352
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3295219
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Remove the previous vmm_vhost::Error enum, as most of its variants are
no longer used. Instead, expose vhost_user::Error as the top-level one.
BUG=b:206900656
TEST=cargo check
Change-Id: Ic5d9f7dcc6e2986d7b51885e2c0f44aa4e012e5f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3295218
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Introduce `Endpoint` trait and add `EndpointExt` trait as its blanket
implementation.
This trait generalizes the existing socket-based endpoint struct and
allow us to add a new VFIO device backend later.
BUG=b:194137301
TEST=vhost-user block device worked
Change-Id: I9c276bbbf14570b67d3c55507054f48e1210d019
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3270299
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
The async interrupt resample thread borrows the interrupt object passed
to it, so borrowing mutably will fail at runtime. The two calls to
interrupt.borrow_mut() were in places that did not need a mutable
reference anyway, so just switch them to interrupt.borrow().
BUG=b:208264646
TEST=Boot crostini on kevin
Change-Id: Ie873273f862b1d4ef11b595596fea51cd202ac6f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3309200
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Make the "video-decoder" and "video-encoder" capable of taking an
argument to explicitly specify which backend should be used. At the
moment there is only one backend (libvda), but this is going to change
soon and this change prepares for that.
The argument-less forms of "video-decoder" and "video-encoder" are also
kept and will select the libvda backend for compatibility.
BUG=b:161774071
BUG=b:169295147
TEST=Android Youtube plays properly on Hatch.
Change-Id: Ia2afd8932dbeabf381a3a2a81424812d50b99d50
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3026350
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
we would like to have all anyhow::Error instances print out
their full context, thus we need to use `{:#}`
BUG=None
TEST=compiles
Change-Id: Iba3d1757e8816cb5d91aa1b9615e5660125c463e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3300823
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Maciek Swiech <drmasquatch@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Create an async_utils module and deduplicate the common async helper
functions there.
In particular, this moves wait_kill (renamed to await_and_exit) and
handle_irq_resample into the new module and replaces all uses throughout
the async device implementations.
BUG=None
TEST=tools/presubmit --quick
Change-Id: If3b5b9f71c8553afa5ccd8c57933ca748fc990e7
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3292635
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
`sys_util::recv_iovecs_with_fds` was implemented as a safe function, but
it was actually unsafe because it assumed that the caller would give a
slice of `libc::iovec` where each `iov_base` points a valid memory
region with `iov_len`.
To make the function truly safe, it should take a slice of IoSliceMut
instead.
BUG=none
TEST=cargo test in sys_util/vmm_vhost
TEST=vhost-user block still works
Change-Id: I45458ee4545af13ce7e0955fb67b3703b147e7df
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3288733
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
This is repeated for each Worker struct creation, so deduplicate it
inside of the run function.
BUG=None
TEST=tools/presubmit --quick
Change-Id: If96ed9cf04f3a57070dfa6018678d5cda51db7f3
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3299122
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Remove the crates.io patch from the top-level Cargo.toml and make
devices point to the third_party/vmm_vhost location directly, since
vmm_vhost has been forked in crosvm and cannot be replaced by the
crates.io version anymore.
Incidentally fixes this warning from cargo:
warning: patch for `vmm_vhost` uses the features mechanism.
default-features and features will not take effect because the
patch dependency does not support this mechanism
BUG=b:205511695
TEST=cargo build
TEST=tools/presubmit --quick
Change-Id: Id29578b57f7540805cf85a3db9a09542b7b84825
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3299125
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
write_all_at()/read_exact_at() fail to access pmc_mux through /dev/mem.
while devmem2 tool success to access them through /dev/mem, so this
commit reference devmem2 implementation and use mmap to access direct
mmio.
BUG=b:199354528
TEST=Apply https://chromium-review.googlesource.com/c/chromiumos/platform/initramfs/+/3194150
, then verify platform device (like typec) function in ManaTEE CrOS
Change-Id: Id69c44444e2dc1ef6d40cb7b36febda38848d4f0
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3259931
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
msix vector table is stored in mmio, its contents is saved and restored by pci bus
dirver during device PM. With vfio-pci device, msix is virtualized and guest pci
bus driver could maintain virtualized msix vector table. But vfio-pci device maybe
poweroff and the physical msix vector table will be lost, crosvm couldn't maintain
physical msix vector table during vfio-pci device suspend and resume.
kernel vfio-pci set msix message for each enabled vector which is specified in
VFIO_DEVICE_SET_IRQS() ioctl, this commit use this to restore physical msix vector
table during vfio-pci device's resume.
__pci_restore_msix_state() is called during device resume, this function set enable
and maskall bit first, then restore msix vetor table, finally set enable bit and
clear maskall bit.
so when enable and maskall bit is set, virtualized msix could be disabled. When enable
is set and maskall is cleared, vituallized msix will be enabled through
VFIO_DEVICE_SET_IRQS() ioctl, and kernel restores vfio-pci device's physical msix table.
BUG=b:185084350
TEST=verify vfio-pci device's suspend and resume function in vm, this device should have
msix capability like TBT controller.
Change-Id: I0a9e91874a9d1ec4b0bb9ff655b83a293daa6865
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3291758
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
When guest poweroff root port, its downstream device could be destroyed
safely, so put the downstream device into
PciDevice->get_removed_children_devices(), then the downstream device
will be removed by pci root.
BUG=b:185084350
TEST=Boot a guest and hotplug vfio pci device repeatedly
Change-Id: Icb8104a2417832864d8dbe4947895028dabb46d6
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2955577
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
When PCIE root port receives poweroff config register write, its
downstream devices could be removed. So get_removed_children_devices()
in PciDevice trait is used to get removed downstream children devices
pci address, then these children devices will be destroyed by pci root.
BUG=b:185084350
TEST=Boot a guest and hotplug vfio device repeatedly
Change-Id: Iea861459b3cbabd7a9daf639ed4b7ad181a81e01
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2955576
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
When vfio-pci device is hotplug out from guest machine, guest will
write some registers to notify the device could be removed from
crosvm, then destroy_device() is used to destroy vfio pci device
from pci_root.
BUG=b:185084350
TEST=Boot a guest and hotplug vfio device repeatedly
Change-Id: I40f72aeb2c12d885f5cf5c8189238bd1cea0c1e9
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2955575
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
When vfio pci device is hotplug out from the guest machine, vfio device's
resource should be returned to system, so vfio pci device's close() is
needed.
BUG=b:185084350
TEST=Boot a guest and hotplug vfio pci device repeatedly
Change-Id: I4686d737e93ae6db6078851e2add3275b9faaa84
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2955574
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
When vfio group is opened at the first time, group is added into
kvm vfio device. In order to support vfio device hotplug repeatedly,
vfio group should be deleted from kvm vfio device when group is
closed.
BUG=b:185084350
TEST=Boot a guest and hotplug vfio device repeatedly
Change-Id: I4a8a18a6a890846f514df12b48a7440786e4e74c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2955573
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
One container could contains multi groups, one group could contains
multi devices, when all the devices in the group are closed, the
group itself should be removed also.
BUG=b:185084350
TEST=Boot a guest with and without passthrough device
Change-Id: Ia43da3e2e9ad58d0a7596141645926931c0bcc5b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2955572
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Vfio pci device's bar are mapped into ept and iommu page table for
hardware acceleration, when vfio pci device is hotplug in the guest,
guest kernel will reallocate the bar, so the old bar address should
be deleted from ept and iommu, and the new bar address should be
added.
BUG=b:185084350
TEST=Boot a vm and hotplug add a device
Change-Id: Icc489917f4c241180bbef412a17917b34fafe7e5
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2955571
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
PcieRootPort implement hotplug_bus trait, it should be added into
RunnableLinuxVm->hotplug_bus, so create pcie root port when
RunnableLinuxVm->hotplug_bus is ready.
Many hotplug bus may exist, when a hotplug device is added, is_match()
should be called on each hotplug bus before attach that device to
the bus.
BUG=b:185084350
TEST=Boot a vm with passthrough device and check its function
Change-Id: I89dbc091f336b3f9d0435b52963f7cf62d408a67
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2955570
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
When pci bridige is created, caller should specify its primary bus
number and secondary bus number. And supposing kernel won't modify
them as the current pci device topology is simple enough, once
guest modify them, warn message will be printed.
The secondary bus number shouldn't be assigned to any other device,
so this patch loop the bus number to find a free bus number.
BUG=b:185084350
TEST=Boot a vm with passthrough device and check its function
Change-Id: Iae72a0e0401a6e75c62582456b92792a1a36211a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2955569
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Passing an open FD is necessary to avoid racing for vsock context IDs:
On Borg, we first want to generate a random, unused CID and pass this to
crosvm. This requires us to open `/dev/vhost-vsock` and call the
`VHOST_VSOCK_SET_GUEST_CID` ioctl on it. Closing the device and simply
assing its path to crovm opens up a time window where an overlapping VM
creation request may set a different CID on the device.
BUG=none
TEST=tools/presubmit --quick
Change-Id: If053e26ba93ab357b06e8cf07798679c8ad06c9e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3263933
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Christian Blichmann <cblichmann@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
In addition to SharedMemory, we allow File (e.g. mmap'd file) to be an
backing object of MemoryRegion.
BUG=b:194137301
TEST=kokoro
Change-Id: I9dafd028eaf74cf34820ba3f16e458c08ec67cb8
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3159883
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
This is a preparation for CL:3159883, where GuestMemory will be backed
by `dyn AsRawDescriptor` instead of `SharedMemory`.
So this CL adds a logic to create a SharedMemory from `&dyn
AsRawDescriptor`.
BUG=b:194137301
TEST=cargo test --all-features in audio_streams
Change-Id: I615be5976184696bcb9ae90928e366276467013a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3159882
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Chih-Yang Hsia <paulhsia@chromium.org>
Define `SharedMemory` trait, implement it for `base::SharedMemory`, and
use it for `ShmStreamSource::new_stream()` so that we can pass on
`base::SharedMemory` without exposing `base` to libcras.
Note that we implement the trait for `base::SharedMemory` in `base`
crate instead of in `audio_streams`, which means `base` depends on
`audio_streams`, because `audio_streams` is available for non-crosvm
projects while `base` isn't.
The corresponding CRAS change is crrev.com/c/3251123.
BUG=b:194137301, b:204444445
TEST=cargo test --all-features
Change-Id: I2430d9881d98032592c9f9202d70deb22e006f63
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3251820
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Chih-Yang Hsia <paulhsia@chromium.org>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Add device label to vfio related error messages to get device name when
debugging
BUG=None
TEST=./tools/run_tests
TEST=./tools/presubmit
Change-Id: I910cbe35dde2d88155f693f90225a2708663d75d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3288284
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Cause panic when it failed to read or write VFIO regions because there
are no ways of recovery.
BUG=b:194137301
TEST=build
Change-Id: I0f6296d1835443641a12d5608b774ec35fdea7e9
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3149872
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
This fixes a bug introduced by [1] when msix pba table offset is smaller than
msix table offset.
An error may occure when booting guest with some vfio devices:
[ERROR:src/panic_hook.rs:90] thread 'main' panicked at 'attempt to subtract with overflow', devices/src/pci/vfio_pci.rs:274:26
[1] 7458a3a19b
So limit the adjustment of table size only if pba table offset is greater than
table offset.
BUG=b:1971693450
TEST=passthrough a nvme which the msix table offset is greater than pba
table offset, boot and verify MSIX-capable passed-through devices work
properly.
Change-Id: I1432c2290feaa5f6db088ebd416dc346547e7952
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3279957
Reviewed-by: Tina Zhang <tina.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>
Developers may need to manually clean up the common/enumn directory - it
will be left behind if there are build artifacts (Cargo.lock, target
directory, etc.):
rm -rf common/enumn
BUG=b:205344148
TEST=cargo build
TEST=tools/presubmit
TEST=emerge-hatch crosvm # with https://crrev.com/c/3265967
Change-Id: I1af3bdd22f40e87895a78a5cbc8033476058c927
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3278774
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
There were not too many cases here. This fixes:
- comparison_chain
- wrong_self_convention
- upper_case_acronyms
- from_over_into
- let-and-return
The collapsible_if check is moved to the permanently
allowed checks. The cases we do have improve
readability or semantics.
BUG=chromium:908640
TEST=Kokoro
Change-Id: I6e905d08e2a87aa0862d4d1cf5ff57b60e95fa7d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3278776
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
This ensures that we can open files whose sizes may be larger than a
32-bit off_t.
BUG=b:181113648
TEST=emerge-kukui crosvm
Change-Id: I2322480dcf507f83609117b4def40846d619b69b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3270100
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
An error occured when passthrough some nvme to a guest based on vfio:
[ERROR:devices/src/pci/vfio_pci.rs:773] add_bar_mmap_msix failed:
Out-of-space detected in MSIX Allocator
Althrough the issue may only happen to some devices whose msix table
overlaps with its msix pba table, as it was mentioned before[1], this
situation must be covered by some validation test. Otherwise, it will
block crosvm booting.
[1] https://patchwork.kernel.org/project/qemu-devel/patch/099db937-3fa3-465e-9a23-a900df9adb7c@default/
BUG=b:1971693450
TEST=passthrough a nvme with a msix table overlapping the msix pba table,
then boot Linux kernel and verify MSIX-capable passed-through devices
work properly.
Change-Id: I602dda95d4671682dc03478415f6a96d7c40ec6e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3152434
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Calling `unshare(CLONE_FS)` from worker threads means we can freely
modify the current working directory and umask without having to guard
theses attributes with locks.
BUG=none
TEST=./tools/presubmit --quick
Change-Id: I29144b3d233b84e761c11a5e46efe541117e7f2a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3263932
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Christian Blichmann <cblichmann@google.com>
Auto-Submit: Christian Blichmann <cblichmann@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Rename Listener struct to SocketListener and introduce Listener trait.
This is a preparation for adding VFIO backend for virtio-vhost-user.
BUG=b:194137301
TEST=cargo test --all-features --all-targets
Change-Id: Iea1e5b4378606b696c4022e3e2e6f4bbf80be55f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3268267
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
This reverts commit 4ceec18783.
Reason for revert: This breaks all ARCVM HW encoding
BUG=b:205488531
TEST=arc.VideoEncodeAccel.h264_192p_i420_vm
Original change's description:
> virtio: video: reject resources with more than one entry
>
> The crosvm video device cannot currently work with resources that have
> more than one memory/object entry. Enforce this rule at the command
> level.
>
> BUG=b:161774071
> BUG=b:169295147
> TEST=Android Youtube plays properly on Hatch.
>
> Cq-Depend: chromium:3247491
> Cq-Depend: chromium:3247492
> Change-Id: Ibfe2e420b4a77062cca940c5e97e7053aa4b76a7
> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3026345
> Tested-by: kokoro <noreply+kokoro@google.com>
> Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
> Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Bug: b:161774071
Bug: b:169295147
Change-Id: Ib24bd8098b37d696b74bc942cdb7c81719d1b8b6
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3267727
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: David Staessens <dstaessens@chromium.org>
Previous commit "devices: Add/Remove device mmio at config memory enable
/disable", it has an assumption that when driver update bar's location,
driver should disable bar's memory/io at first.
But some driver reallocate bar's address even with memory/io enabled,
this commit monitor bar's config write, if address is modified, it
return this modification.
BUG=b:174705596
TEST=boot a vm, monitor resource reallocation and check function.
Change-Id: I9aa883192f5e2fec344d3e86c818c7a29287f49a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3184726
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
get_bar_configuration() returnis bar's info, this ignores memory/io enable
bit. Usually driver disable memory/io first, then wrtie 0xFFFFFFFF to
probe bar's existence and size, finally write real address and enable
memory/io.
if get_bar_configuration is called after mmio/io disabled, current
it may return invalid info. In order to filter these invalid info,
this commit checks memory/io enable bit, only return info at memory/io
enabled.
BUG=b:174705996
TEST=carto test -p devices
Change-Id: Ib8bf1a7f7f959025117f319f8f6c5a9e5efea2e2
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3252779
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
When initializing the device for encoding the underlying encoder
session is immediately brought up, as this is required to determine
parameters such as the desired output buffer size. This causes further
configuration changes to be refused, even when the device isn't
encoding anything yet. This CL makes changes to allow configuration
changes by recreating the encoder sessions as long as no buffers have
been queued.
BUG=b:203608233
TEST=tast run DUT arc.VideoEncodeAccel.h264_192p_i420_vm
Change-Id: I7e9d8b41ea2497b5d86aaca7db7ed13af056f11d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3252185
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: David Staessens <dstaessens@chromium.org>
We need the access id for some future changes that will be posted soon
for a userspace irqchip.
Each vcpu will have a clone of the Bus itself, not the Arc<Bus>, so that
they can each have their own access id.
This also adds a call to set_access_id to run_vcpu.
BUG=b:160610704
TEST=ran local presubmit, and ran test image
Change-Id: I4afb0ef9c234f25150ce2f89d6fb228ad5b88745
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3261627
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Colin Downs-Razouk <colindr@google.com>
The current way for building a codec device is to call the corresponding
constructor method of the backend we want to use. However doing this
forces us to pass the resource bridge to these constructors, introducing
dependencies from the backend to parts of the code that are not used
otherwise.
Switch the construction method to one constructor per backend, which
only takes the arguments relevant to the backend, and one device
constructor that takes the backend to use as parameter.
BUG=b:161774071
BUG=b:169295147
TEST=Android Youtube plays properly on Hatch.
Change-Id: I493f421e982a1d2ba8292a69bae575afeee17e4c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3026349
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
We have two separate features for video decoder and encoder, but
selecting any of them results in all the video code being included. Add
some #[cfg] statements to compile out the unneeded code if only one of
the features is selected.
BUG=b:161774071
TEST=`cargo build` passes without warning
TEST=`cargo build --features "video-decoder"` passes without warning
TEST=`cargo build --features "video-encoder"` passes without warning
TEST=`cargo build --features "video-decoder,video-encoder"` passes without warning
Change-Id: I3e5f2173695ee9dd5e8d26ace14374d426e570a6
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3026347
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Make the backends accept our generic resource types as inputs instead of
expecting virtio objects. This makes the backends able to deal with any
kind of resource, the counterpart being that they must now check what
kind of resource they received. The VDA can only deal with virtio
objects and will reject other kinds of resources.
On top of making backends not limited to virtio objects, this is also
safer than passing FDs because it becomes clear when we are transferring
ownership of a resource, and when we need to clone them. Also since
resources carry information about their layout, the number of arguments
we need to pass to the backends is reduced.
BUG=b:161774071
BUG=b:169295147
TEST=arc.VideoDecodeAccel.h264_vm passes on hatch
TEST=arc.VideoEncodeAccel.h264_360p_i420_vm passes on hatch
TEST=GtsExoPlayerTestCases com.google.android.exoplayer.gts.DashTest
passes on hatch
Change-Id: I09dd81bac13a46fa908a4107a376fa7d59fb9759
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2983096
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Currently the video device only accepts virtio objects (as file
descriptors) for resources, and file descriptors are hard-coded a bit
all over the place to represent buffers and frames. This causes two issues:
1) Multiple buffers cannot currently be used to represent frames, i.e. 1
frame is exactly one virtio object,
2) Resources that are not virtio objects, like guest memory, cannot
be used at the moment.
This patch introduces more flexibility in the way resources are handled:
first, all the resource-related code, including their resolution using
the resource bridge, is consolidated into a new resource module. Then,
the command module does not arbitrarily decide that all resources are
virtio objects, and leaves that decision to the queues. Finally,
resources now have their enum type that can unfold into any of the
resource types we will support (currently only virtio objects). This
forces consumers of resources to check their type before using them.
Semantically, very little should change. The only noticeable side-effect
should be that we now call the resource bridge only once per input
buffer instead of once per decoder operation.
BUG=b:161774071
BUG=b:169295147
TEST=arc.VideoDecodeAccel.h264_vm passes on hatch
TEST=arc.VideoEncodeAccel.h264_360p_i420_vm passes on hatch
Change-Id: I93b203117b5c96e91d4f1b8007e95ec5c501ea5f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2983095
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
The crosvm video device cannot currently work with resources that have
more than one memory/object entry. Enforce this rule at the command
level.
BUG=b:161774071
BUG=b:169295147
TEST=Android Youtube plays properly on Hatch.
Cq-Depend: chromium:3247491
Cq-Depend: chromium:3247492
Change-Id: Ibfe2e420b4a77062cca940c5e97e7053aa4b76a7
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3026345
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@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>
When device memory/io is disabled, its mmio/io range should be
removed from mmio_bus/io_bus.
When device memory/io is enabled, its mmio/io range should be
added into mmio_bus/io_bus.
BUG=b:174705596
TEST=Boot a vm, monitor device mmio/io enable/disable, then check
vm function.
Change-Id: Ic77565b9828599d574329bea76146cff597a94fe
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3252778
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
When device's bar are reallocated, all the old resource ranges should be
deleted, the new resouce ranges shoud be added, this commit add the
interface to get device mmmio/io old/new ranges.
BUG=b:174705596
TEST=Boot a vm, monitor device bar reallocation and check function
Change-Id: I1000607d9f766ff8b445bf92f17969b094f3b2ae
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2718280
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
When device's bar is reallocated, the old ranges will be deleted,
this commit add remove() function to delete one old range from
bus->devices.
BUG=b:174705596
TEST=Boot a vm, monitor Bar Reallocation then check function
Change-Id: Id0600ae1d7a3d04c7f05a90abcc8807b7f1020c3
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3184725
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
This change contains the results of running
./tools/contib/cargo_refactor.py
This will break the next uprev, and needs to be synchronizized
with the corresponding ebuild changes in https://crrev.com/c/3248925
BUG=b:195126527
TEST=./tools/run_tests
Change-Id: Ied15a1841887bb8f59fba65b912b81acf69beb73
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3248129
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Introduce a very simple stub PCI device that can be added to the bus
at a specified address with given PCI config parameters (vendor,
device, etc.). This is useful for cases where we just require a device
to be present during PCI enumeration.
The case that motivates this is a vfio device passthrough
configuration that passes only selected functions of a given device at
the original addresses, but function 0 is not passed through. Absence
of function 0 would be interpreted in enumeration as the entire device
being absent (in accordance with the specification). Putting a stub
device at function 0 fixes this.
BUG=b:167947780
TEST=New unit test, boot minimal Linux image and verify enumerated PCI device.
Change-Id: Iaedffe1c4ac2ad8f6ff6e00dfeebbbfeb5490551
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3245497
Auto-Submit: Mattias Nissler <mnissler@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Mattias Nissler <mnissler@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
This is useful for example when parsing numeric PCI class code values
from the command line.
BUG=b:167947780
TEST=None
Change-Id: I55515af2fa7e38bc26f4c2eebb083f1e45aebf22
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3245496
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Mattias Nissler <mnissler@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
It's the highest bit in the header type field, this change allows to
set the bit and thus indicate that a device is a multifunction device.
BUG=b:167947780
TEST=None
Change-Id: I71372e2490897bc3d5c24717c9504e337792a48f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3245495
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Mattias Nissler <mnissler@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Like disks, serial devices can be backed by file descriptors using the
/proc/self/fd/N syntax.
BUG=b:200914564
TEST:cargo test
Change-Id: Idd6f5763db24e61a80dc34732c9e2118d613cefc
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3241083
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Rust bindgen now supports --allowlist and --blocklist option names as of
https://github.com/rust-lang/rust-bindgen/pull/1990 - use them in the
various bindgen invocations in scripts and comments.
BUG=b:178821708
TEST=../dev/contrib/search_blocked_words.sh unblocked_terms.txt
Change-Id: I9797f049999a01ab2c41617823463236b4d03cbb
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3243012
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
According to pci bridge spec, the io/mem/prefetch mem limit register
must be programmed to a smaller value than the corresponding base register
if there is no io/mem/prefetch mem on the secondary side of the brige.
When bridge is created, it doesn't have any child device, then
no io/mem/prefetch mem on the secondary side of the bridge, so this
patch set limit to 0, but base to 0xffff.
When a device is attached behind the bridge, kernel will assign
resource and set the right value to these base and limit register.
BUG=b:199442120
BUG=b:185084350
TEST=crosvm run --bios OVMF.fd
TEST=hotplug in/out a pcie device to pcie root port repeatly
Change-Id: Id1c2ff1132d59e1aafd548fc17ab5aee2023dd8c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3166883
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
With vfio pci device hotplug, bus->devices will be inserted and removed at
runtime in different vcpu threads, so mutex should be used to protect it.
Both each vcpu thread and pci_root share mmio_bus and io_bus, so use Arc
for mmio_bus and io_bus. But pci_root is inserted into io_bus for pci cfg io,
in order to resolve reference loop and memory leak, weak is used for
pci_root.mmio_bus and pci_root.io_bus.
BUG=b:174705596
TEST=boot a vm and check its function
Change-Id: I7b3e63db76a90bc3873619b4d80a66db741ce78f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3184724
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
The strategy of passing Vec<u8> types introduced in crrev.com/c/2470376
can cause panics when the receiving side doesn't have the capacity to
receive the full buffers produced by crosvm. For example, a
virtio-console implementation with only one-byte buffers
(https://android-review.googlesource.com/c/1853082) almost always won't
have the capacity to receive the full buffers.
Using a VecDeque ring buffer allows continually appending data from the
input in the read thread and pulling off as much as the guest can handle
in the guest communication thread, without sacrificing performance when
the guest can handle higher volumes.
Bug: b/182849835
Bug: b/203138623
Test: Pass some input with an unbuffered single-character console driver
Test: Run CtsKeystoreTestCases against cuttlefish (high volume transfers)
Change-Id: I6b52a729d5af82f4626a9b1f29176116299b9297
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3227733
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Cody Schuffelen <schuffelen@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
