Use our new serde_keyvalue crate to annotate the SerialParameters
structure and allow us to create it from a key-values string. Add tests
to help ensure parsing doesn't break in the future.
The existing arguments can be parsed identically by this new code, so
replace the old serial options.
BUG=b:218223240
TEST=cargo test -p devices serial_device::tests::params_from_key_values
TEST=cargo test parse_serial
Change-Id: I4898a45399b69b87a44f80d3a214daf081b06173
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3439670
Reviewed-by: Anton Romanov <romanton@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Fill the fd offset into the VmMemoryRequest::RegisterMemory source field
now that it is supported.
BUG=b:194136484
TEST=tools/presubmit
Change-Id: I9f8ae069d73cf0974bb739a768b731d6b0c289ca
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3508321
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
The values that were cast in these expressions were already MemSlot, so
there is no need to cast back and forth between MemSlot and u32.
BUG=None
TEST=tools/presubmit
Change-Id: I8a215bc50d10a93b21f6d2fe7e4ed7267242a50b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3508320
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Many of the subtypes of VmMemoryRequest share similar or exactly
identical code, but it is difficult to tell how they differ and what
each variant does. Reorganize the various memory registration requests
into a single RegisterMemory variant with orthogonal source and
destination structures to unify the shared functionality into a single
implementation.
BUG=None
TEST=tools/presubmit
TEST=Boot Crostini on trogdor
TEST=Boot Crostini on hatch
Change-Id: I059ce40b90812067e5ec882320ea7c8b6a3cc0fd
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3470539
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Abhishek Bhardwaj <abhishekbh@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
add_bind_mount is a unix specific function that uses only public
fields of SerialParameters. So moved the function closer to call site.
Bug: b:213149155
Test: cargo test and presubmit
Upstream-Crate: devices
Change-Id: I05232c10ddc474421b6dba4ff34ecec9965c3913
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3543886
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Vikram Auradkar <auradkar@google.com>
Add optional `uuid` argument to `--vvu-proxy` so a user can specify a
UUID that will be stored in virtio_vhost_user_config space so that the
guest can read the value by reading /sys/devices/pci*/*/resources.
We can use this value to allow the guest to know the socket path that
the VVU proxy device uses.
BUG=b:215472603
TEST=pcimem /sys/device/pci.../resource0 0x2008 b*16,
where 0x2008 == (DEVICE_CONFIG_BAR_OFFSET + offset in vvu config)
Change-Id: I99f1d988cb793b44682ddf927837139dabd42cf8
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3516669
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Auto-Submit: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Unfold the anyhow errors returned so we can identify their source
precisely.
BUG=None
TEST=cargo build
Change-Id: I5bdfcc893b7ca98d83561cac820bcee443013547
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3543011
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
At the moment compiling with the "virgl_renderer" feature enabled but
"x" disabled results in a link error because the virgl_renderer enables
all its platforms without checking. Fix this by enabling the glx
platform only if the x feature has also been enabled.
BUG=b:226033718
TEST=`cargo build --features "virgl_renderer"` passes.
TEST=`cargo build --features "virgl_renderer,x"` passes and enables GLX
in virgl_renderer.
Change-Id: I85041fc2a3db7e49415add69389bee3160ba4a5b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3539327
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
This commit uses physical pcie hotplug GPE as virtual hotplug event
trigger point.
When virtual pcie root port gets such physical GPE notification, it
will prepare hotplug and inject PME to wakeup virtual pcie root port,
once virtual pcie root port is waken up, it will let host pcie root
port to rescan and probe the added new pcie device, finally request
crosvm to add the new pcie device into CrOS.
BUG=b:185084350
TEST=Verify TBT pcie hotplug function in ManaTEE
Change-Id: I5d02582d0eb9bcfd9d8998065ccc758c91169f81
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3520985
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
When specific GPE event happens, some devices want to get notification.
For example, virtual pcie root port wants to get notification when
acpi hotplug GPE occurs. So virtual pcie root port implements this trait.
When virtual pcie root port gets this hotplug GPE notification, it will
inject a PME into CrOS, CrOS PME handler will wakeup virtual pcie root
port and TBT DMA engine, and forbit them to enter into suspend again
during hotplug process.
Once hotplug process is finished, virtual pcie root port and TBT DMA
engine could be allowed to suspend again.
BUG=b:185084350
TEST=Verify TBT pcie hotplug function in ManaTEE
Change-Id: I6c984e4f81713ad34383f1fb4ea2a5776ac2fccf
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3539565
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Use the cross-platform base::Event type to replace the Linux-specific
base::EventFd.
BUG=b:221882601
BUG=b:219522861
TEST=tools/presubmit
Change-Id: I0503c130306b508af9dd5044653408bd316c7ef1
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3533618
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Upstreams support for Tubes on Windows, splitting Tube into platform
specific files. This contains several critical enhancements:
* POSIX Tubes support multi producer multi consumer configurations, but
Windows has remained strictly SPSC for each direction. Windows cannot
support MPMC, and that configuration is not really something we want
either. To address that, this CL introduces directional Tubes. A
SendTube is clonable, and a RecvTube is not, which gives us MPSC.
* This CL also fixes multiple interface conflicts that have developed
between Linux & Windows:
+ send wasn't async on the Linux AsyncTube.
+ send data wasn't passed as owned on the Linux AsyncTube.
+ Adds the 'static constraint for AsyncTube::send on POSIX. This is an
requirement on Windows.
+ Event::read_timeout doesn't need to take &mut self, and it wasn't
downstream. This CL switches to &self.
* Adds the missing notifier.rs file in base.
Note that this CL does not attempt to remove balloon's usage of
Tube::try_clone. That's a somewhat involved issue that should be tackled in
its own CL.
Test: tested downstream on Windows & Linux bots, upstream on Linux bots.
Bug: b:221484449
Change-Id: I288dbc1d1e42f8ce08258cdaaf85100ca93721ef
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3536897
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Noah Gold <nkgold@google.com>
The virgl renderer was unconditionally selected as the default backend
for crosvm, even if the "virgl_renderer" feature is not enabled. This
forces the user to explicitly specify the 2d backend with the --gpu
option, which can be confusing for new users.
Simplify things a bit by using the 2D renderer as default if the
"virgl_renderer" feature is not enabled - that way the GPU can be used
without having to specify a backend explicitly.
BUG=b:213532598
TEST=successfully run crosvm without the "virgl_renderer" feature and
without specifying the "backend" GPU option.
Change-Id: Ib36b7d92cef62d9dd91b0a41051362d1c57e0536
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3528233
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Rearrange the code to make sure that if direct GPE feature is used then
it is enforced that both host SCI events and GPE list are supplied when
instantiating ACPIPMResource.
BUG=None
TEST=./tools/presubmit
Change-Id: Ib44e217b09344b1c6bed091312eb196863ca2fee
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3537264
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dmitry Torokhov <dtor@chromium.org>
We make a copy of the data when creating instance of ACPIPMResource, so
let's use slice to pass the data around.
BUG=None
TEST=./tools/presubmit
Change-Id: Idf9627c4ef6aee86fa9de4d1c24ec45aa684432e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3537263
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dmitry Torokhov <dtor@chromium.org>
base was previously providing some async types which now would
cause a circular dependency. Those have been moved into cros_async.
BUG=b:22320646
TEST=presubmit
Change-Id: I1f526ccfc5882f3a64404f714b13ac92ebfddcd6
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3533614
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Upon receiving acpi event related to ACPI button notification emulate
PM/PWRBTN_STS and trigger SCI.
BUG=None
TEST=After enabling CONFIG_ACPI_BUTTON on hypervisor kernel, check if
power button events are propagated to the guest by reading
/sys/firmware/acpi/interrupts/ff_pwr_btn counter.
Change-Id: Ie52c58d0934fb6657940bdca35dfbc68a8f4f42c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3521728
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Tomasz Nowicki <tnowicki@google.com>
Ignore ACPI netlink events for GPEs which are configured as direct
GPEs. Such GPEs are forwarded to the guest directly as physical GPEs
using eventfd based forwarding of physical SCI interrupts (which
ensures that the GPE handling in the guest is synchronized with SCI
interrupt context in the host).
Forwarding via netlink should be used for emulated GPEs only.
With this change, we are still propagating all GPE events received by
the host to the guest. In the future we may need to enhance this logic,
since for some types of GPEs we may not want to inject them to the
guest at all, e.g. for Thunderbolt hotplug GPE we want to receive it
in crosvm and then inject a normal PCI hotplug interrupt instead.
BUG=b:197247746, b:205072342
TEST=Make sure that GPE marked as direct are ignored
Change-Id: Id5b05a99951455f52dcb375289cb10d040e8ff7f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3492225
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Tomasz Nowicki <tnowicki@google.com>
In order to listen on acpi_mc_group of acpi_event family there is need
to query kernel about it's group id, which is next used to create ACPI
event related socket. This socket is next used during ACPI PM worker's
wait context build.
Upon receiving ACPI events, dispatch them by device class and in case of
receiving "gpe" one, emulate proper vGPE and inject vSCI to the guest.
BUG=b:197247746, b:205072342
TEST=Receive, parse and use GPE generated by ACPI events. With use of
additional kernel patches make sure that GPE notifications are correctly
received, emulated and vSCI injected to the guest.
Change-Id: I18bdfe18ebb1e5bcfa7277b91ae195a61fac1a3d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3407321
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Tomasz Nowicki <tnowicki@google.com>
In ACPI world multiple GPEs (HW wires signaling arbitrary event)
can be associated with single SCI. Any pending GPE causes SCI
to be fired and appropriate GPE handler dispatched. In order
to pass-through GPE to the guest and take virtualization actions,
host kernel provides mechanism to bind physical GPE with SCI eventfd and
forward that information the the event listener (crosvm or KVM most likely).
Add userspace counterpart to host kernel GPE forwarding module
implemented in CL:3488959.
BUG=b:205072342
TEST=see CL:3492224
Change-Id: I1179baa78339bdd78f3fabf0139eb6f61f90eb2b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3439889
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Commit-Queue: Tomasz Nowicki <tnowicki@google.com>
In order to allow handling physical GPE in the guest, implement GPE
status & enable register bits read/write passthrough to/from physical
registers for selected GPEs (while for the rest of GPEs the registers
remain purely emulated).
We use Linux kernel's ACPI sysfs interface for accessing physical
GPE regs. Note that in particular for enabling/disabling GPEs we use
"mask"/"unmask" interfaces instead of "enable"/"disable", since we
want to do raw enable/disable, bypassing ACPICA's reference counting.
We only do "enable" when it is enabled for the first time, to ensure
that the ref count for the given GPE is > 0.
This of course assumes that the given GPE is enabled/disabled
exclusively by the guest, never by the host.
Thanks to Peter Fang for the idea to use mask/unmask.
BUG=b:205072342
TEST=see CL:3492224
Change-Id: I20c08d371710f89b359ac5e8677f22165811eb84
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3492222
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dmytro Maluka <dmy@semihalf.com>
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Commit-Queue: Tomasz Nowicki <tnowicki@google.com>
In order to allow handling physical GPE in the guest, implement
physical SCI interrupts forwarding from the host to the guest.
It uses an eventfd based mechanism similar to how we normaly do
forwarding of other level-triggered interrupts. The difference is that
SCI trigger events from kernel are not injected directly to irqchip.
In order to support injecting both physical and virtual SCI interrupts
(so that some GPEs can be handled as physical while other GPEs can be
emulated), SCI trigger event is intercepted by ACPIPMResource which
injects it to irqchip via another eventfd - the same eventfd which is
used for injecting virtual SCI interrupts.
Similarly, resample event for physical forwarded SCI is received
via the same eventfd as for virtual SCI, then forwarded back to kernel.
BUG=b:205072342
TEST=see CL:3492224
Change-Id: I480a3000d69305aabc777e193d3453c476d2dbbd
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3492221
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dmytro Maluka <dmy@semihalf.com>
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Commit-Queue: Tomasz Nowicki <tnowicki@google.com>
In order to ensure proper emulation of PM1 and GPE events for the guest
and prevent lost events, upon receiving SCI resample event we need to
trigger SCI interrupt again if the status of some of the virtual PM1 or
GPE events is still not cleared, i.e. if:
a. the guest has received the last PM1 or GPE event but hasn't cleared
it for some reason.
or
b. the guest hasn't received the last PM1 or GPE event because it was
processing the previous SCI (i.e. SCI was masked in the guest).
BUG=b:205072342
TEST=inject GPE or power button event from command line
and inspect /sys/firmware/acpi/interrupts/
Change-Id: Iff9f9812328823b1876721fbb4be9d0e937f2737
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3492219
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Tomasz Nowicki <tnowicki@google.com>
In preparation for implementing SCI resample handling which will work
in a separate worker thread, implement Pm1Resource and GpeResource
to access virtual PM1 and GPE regs concurrently using Arc<Mutex<...>>.
BUG=b:205072342
TEST=inject GPE or power button event from command line
and inspect /sys/firmware/acpi/interrupts/
Change-Id: Icf7e845cf21fd9d1edcb91db26632e202b7b8434
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3492218
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Tomasz Nowicki <tnowicki@google.com>
KVM irqchip treats differently edge vs level triggered IRQ.
By registering SCI without resample event, we might see unexpected
misbehavior. Since SCI is level-triggered IRQ pass corresponding
resample event even though we don't utilize it right now.
Also store the new event as part of ACPIPMResource for future usage.
BUG=b:205072342
TEST=inject GPE and inspect /sys/firmware/acpi/interrupts/
Change-Id: Ib27f98bbef56ea4ca18da5bf4428bf45bf115882
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3439888
Reviewed-by: Micah Morton <mortonm@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Commit-Queue: Grzegorz Jaszczyk <jaszczyk@google.com>
This will be used by both the ffmpeg and the libva decoder backends, so
merge it ahead-of-time so both backends can be developped independently
from main.
BUG=b:169295147
BUG=b:214478588
TEST=cargo build --features "video-decoder,libvda"
TEST=with crrev.com/c/3026355: cargo test --features "video-decoder,ffmpeg" -p devices virtio::video
Change-Id: Ie00be77b8c0c024b89bff5a5458e62b175fa70ac
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3482936
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Linux expects that PCI bars lie within a compatible bridge window, which
are typically specified via _CRS objects in ACPI. This change adds an
option to restrict mmio allocations (i.e. PCI bars) to within a
specified set of ranges. The specified set of ranges is intersected with
the default mmio allocation ranges generated by the crosvm arch code to
produce the final mmio allocation ranges.
This change is required to remove pci=nocrs from the CrOS guest's kernel
command line flags. Removing that flag is a prerequisite for enabling
virtio-iommu, since without the configuration information from ACPI, the
kernel reserves all IOVAs in iova_reserve_pci_windows.
BUG=b:181736020
TEST=boot manatee w/o pci=nocrs kernel cmdline flag
TEST=tast run trogdor|hatch arc.Boot.vm
Change-Id: I0a096420c5d5ef56dd76021951968e264ce40f42
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3499900
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: David Stevens <stevensd@chromium.org>
Remove the ramoops region from high_mmio when constructing the system
allocator. This means the aarch64 code no longer needs to manually
adjust high_mmio when determining the pci regions.
BUG=b:181736020
TEST=Check arcvm pstore still works
Change-Id: I81ca398a1984f0efb30c0a4d4b620bd50fe9df85
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3516667
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: David Stevens <stevensd@chromium.org>
In order to avoid deadlocks (when a Vcpu thread has locked the ioapic and
the ioapic sends a AddMsiRoute signal to the main thread which itself may
be busy trying to call service_irq) KvmSplitIrqChip defers IRQs by using
vector of delayed IRQs and queuing it up for the next main thread loop
spin.
The problem is that next loop spin will ever happen if there will be
any *unrelated* trigger event to be serviced which means IRQ reinjection
may take really long time, at least longer than some devices may assume
before timeout.
Instead of relaying on non-deterministic mechanism, make sure the next
trigger event for main thread is around the corner by:
- adding a new event - strictly related to processing delayed IRQs
- adding a new token type in main thread and correlate the new event
occurrence with process_delayed_irq_events() irqchip call
- writing to the new event as soon as new IRQ is added to the delayed
vector
This makes sure that delayed IRQs (if present) are always on main loop's
TODO list.
BUG=b:184871003
TEST=boot guest using crosvm --split-irqchip flag and check if IOAPIC
related IRQs are working
Change-Id: I89e731f19a7fa5215cd4a57fa5c94a89a7c9161a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3494286
Reviewed-by: Colin Downs-Razouk <colindr@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Tomasz Nowicki <tnowicki@google.com>
Stop using Tube::try_clone() as we want to remove this method.
This requires a change in how the GPU device tube is set. Cloning the
control tube on the VMM side allowed us to pass only one tube to the GPU
device, which received the first message asking for BAR information and
then immediately recycled its tube to send VmMemoryRequests.
Without cloning, we to create two full Tubes and pass the VmMemory tube
as part of the first message to the device. This is a bit more involved
but also safer.
BUG=b:222379833
BUG=b:221484449
TEST=`cargo run device gpu` replies to the initial message and receives
the tube from the VMM process.
Change-Id: I5c85c7c54ab7be0eba322d1884da7076398c4095
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3499911
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
The API allows audio_streams to be used by crosvm and libcras while
their implementations of cros_async may diverge in the future.
BUG=b:223624364
TEST=./tools/presubmit and emerge tests
Cq-Depend: chromium:3519246
Change-Id: I08b6bf12e02c211275c11f1886f23f71217e40b4
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3518657
Reviewed-by: Chih-Yang Hsia <paulhsia@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
In order to emulate IOAPIC pins and still be able to inject IRQs
via KVM eventfd, SplitIrqChip driver allocates input and output eventfd
for each pin:
- the input eventfd listens for incoming events (e.g. physical IRQ
occurrence or userspace emulated IRQ). This gives chance to to emulate
pin states before handing over to KVM
- the output eventfd inject the actual virtual IRQ in KVM standard manner
Once the guest tries to configure a new IOAPIC pin, the output event GSI
number is allocated dynamically. So there is no chance to know GSI number
upfront to expose it via e.g. ACPI. This is the blocker for direct IRQ
forwarding where 1:1 mapping is inherent feature.
Allocate output eventfd vector and fill in with 1:1 GSI mapping upfront
only for direct configuration feature. Any potential guest IOAPIC pin
configuration request will used pre-allocated GSI number so that guest
will see proper IRQ number. No functional changes for the rest of the cases.
BUG=b:184871003
TEST=boot guest using crosvm --split-irqchip flag and check if IOAPIC
related IRQs are working
Change-Id: Ie1578a831ff21489e4e7dd9c7ec3f5384b4af16a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3494285
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Steven Richman <srichman@google.com>
Commit-Queue: Tomasz Nowicki <tnowicki@google.com>
- Add vGPE registers to ACPIPMResource and inject vSCI when a GPE is
enabled and its event is received.
- Add a new interface, gpe_evt(), to trait PmResource.
- Always use vGPE, regardless of FADT forwarding.
- Always advertise support for 256 GPEs [1] to reduce code complexity.
[1] "Up to 256 GPEx_STS bits and matching GPEx_EN bits can be
implemented." 5.6.1, ACPI Spec Version 6.4
BUG=b:199383670
TEST=boot Linux kernel and inspect /sys/firmware/acpi/interrupts/
Change-Id: I97687326e9313c26b84dfacade5c8741719e7841
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3350493
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Tomasz Nowicki <tnowicki@google.com>
- Add a new trait, PmResource, for PM-related public interfaces.
- Use SCI_INT in FADT as vSCI if FADT is forwarded.
- Inject vSCI if ACPI fixed power button is enabled and a power button
event is received.
- Disable MPTable generation if FADT is forwarded [1].
[1] MPTable generation in mptable.rs makes certain assumptions about
SCI which is incompatible with FADT forwarding. MADT takes
precedence over MPTable in the Linux kernel so hopefully things
should work correctly.
BUG=b:199383670
TEST=boot Linux kernel and shut down
Change-Id: Icc93c3e7492e44b3a5badc5e75373c472c9b9791
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3350491
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Tomasz Nowicki <tnowicki@google.com>
- Refactor read() and write() for ACPIPMResource to protect against PIO
accesses across PM1 register boundaries, and properly support byte
accesses.
- If compiled with the feature "direct", all writes to SLP_TYP are
interpreted as S5 since _Sx is platform-specific.
- Remove Sleep Control and Status Registers since they are only used on
HW-Reduced ACPI systems.
BUG=b:199383670
TEST=boot Linux kernel and shut down
Change-Id: Iaf9fdf5a161eb6f5618235c3a66f8817258ce289
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3350489
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Tomasz Nowicki <tnowicki@google.com>
As a step toward creating a well-defined base API distinct from
sys_util, remove the wildcard `pub use sys_util::*` and individuall
export just the types, functions, and macros that are intended to be a
part of the public base API.
The only functional change is that the net namespace is flattened into
the top-level base namespace, since it inconsistent with the rest of the
API. (sys_util is not affected and still exports mod net, but base does
not.)
BUG=None
TEST=tools/presubmit
TEST=emerge-hatch crosvm
TEST=emerge-trogdor crosvm
Change-Id: I4028d3489cb3816ec9b8d609b3957db8825eb63d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3500062
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Vikram Auradkar <auradkar@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
This change fixes the Worker run function infinitely looping when the
sibling disconnects.
BUG=b:194136484
TEST=Test with sibling VM with Vhost master connecting to a device VM.
Change-Id: I7bce45dd50919d5aead6749932d33036c263f322
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3463214
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Abhishek Bhardwaj <abhishekbh@chromium.org>
Auto-Submit: Abhishek Bhardwaj <abhishekbh@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Add error checking so invalid user input does not get silently ignored
and converted into bogus addresses.
Also add a PciAddress::new() function that accepts numeric values and
checks their ranges as a helper for the string parsing function as well
as for general use in other cases.
BUG=None
TEST=cargo test -p devices pci_address
Change-Id: I1131716bfd99e1819e7630021048482c2397b137
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3475440
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Some changes made it through without clippy testing. Fixing these
now.
BUG=None
TEST=./tools/clippy
Change-Id: If369354042691181d5a251e5707b85672757330b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3508311
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
PCI virtual configuration space is a set of virtual registers similar to
PCI configuration space, but for the guest to configure the hypervisor.
One use case is to facilitate ACPI forwarding at API level.
BUG=b:194390621
TEST=builds
Change-Id: I7902d8f589d19426c8b81629722abbf5c68a905a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3344575
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Victor Ding <victording@chromium.org>
Auto-Submit: Victor Ding <victording@chromium.org>
This change fixes a bug in the VVU proxy device where the main thread
would block until a sibling connected to it. This may disrupt the device
from writing and reading bars from it as those operations happen on the
main thread. Instead, the socket accept logic is now moved to the
beginning of the worker thread and the main thread is unblocked.
BUG=b:194136484
TEST=Run device VM without --disable-sandbox.
Change-Id: I4e3344df20a80316316f2b586c52c8c1a88cc36d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3457900
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Abhishek Bhardwaj <abhishekbh@chromium.org>
Auto-Submit: Abhishek Bhardwaj <abhishekbh@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
When a vfio pci device is hot-plugged in, its vfio container should be
passed to the virtio-iommu worker for later dynamic mapping/unmapping
requests.
BUG=b:185084350
TEST=Boot a guest, hotplug in and out a vfio-pci
device repeatedly
Change-Id: Ia2a9c9ef4a3ee6399d90aa17c6656acb52647663
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3476650
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Virtio-iommu device can generate viot using pci ranges. After adding a
vfio device, guest can attach this device to virtio-iommu.
BUG=b:185084350
TEST=Boot a guest with vfio device and 'iommu=viommu', another PCI range
node is generated in guest viot.
Change-Id: I9204d8bd341b6e544a62923164d5c8ce46fdd8bf
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3476649
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
A tube channel is needed for the communication between main process and
virtio-iommu worker thread, e.g. passing a vfio container file
descriptor of a hot-pluggable device to the virtio-iommu backend which
is in charge of the mapping/unmapping for the endpoint.
BUG=b:185084350
TEST=Boot a guest with no error
Change-Id: Ib5061e795227040ca400bc9a92df84a27cd26438
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3301703
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
For nonroot vfio-pci device, its prefetchable bars will be allocated
in continuous region, its nonprefetchable bars will be allocated in
another continuous region. Without descending the bar's size, this
allocation waste some mmio.
For example, a vfio-pci device has two non prefetchable bars:
bar0's size is 1M, bar2's size is 8M.
without descending [bar0, bar2], it will allocate 16M mmio, 0~8M
for Bar0, 8~16M for Bar2, although bar0 need 1M only, it occupy 8M
to satisfy bar2's 8M alignment requirement.
With descending [bar2, bar0], it will allocate 9M mmio, 0~8M for
bar2, 8M ~ 9M for bar0.
BUG=b:185084350
TEST=check pcie rp's bridge window in brya-manatee.
Change-Id: I7d93e601f6a46cabe8896aaec065a9dba18c60fa
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3500060
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Bridge window's mmio alignment went wrong during our refactor, fix
it in this commit.
BUG=b:185084350
TEST=Check bridge window and pci device mmio setting in CrOS
Change-Id: Ia1a01d1740f943ec7aa36812defe3aabffcfcbde
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3498219
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
On manatee, a vfio-pci could hotplug into an empty pcie rp when
device's host bus number is in pcie rp's bus range.
But on non-manatee, only one virtual pcie rp is created for device
hot plug, it owns one free bus number only, if a vfio-pci device's
host bus number isn't equal to rp owned bus number, this vfio-pci
device couldn't be added into guest through hotplug, so this commit
change is_match() and allow vfio-pci hotplug onto any empty pcie rp.
BUG=b:185084350
TEST=hot plug in/out a vfio-pci device with host bus_number different from
RP's bus range repeatedly in non-manatee.
Change-Id: I9a1059edd9558683e03d85235e0d164b2aa23672
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3498218
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
This snuck through as our builders were temporarily not checking
clippy in presubmit. See https://crrev.com/c/3498847
BUG=None
TEST=./tools/clippy
Change-Id: I38ca27728ab4e108539407f5499484c2b881dc47
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3499740
Auto-Submit: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Anton Romanov <romanton@google.com>
Commit-Queue: Anton Romanov <romanton@google.com>
Add a flag to the adjust command that allows the command to fail. When
this flag is set, a reply is sent with the balloon size at the end of
adjustment.
The flag also changes the semantics of inflation somewhat. By default,
the balloon driver will indefinitely retry if it fails to allocate pages
during inflation. When the flag is set, the device reacts to puff
failure notifications on the event queue by setting the target num_pages
to the current balloon size, to abort and fail the inflation attempt.
BUG=b:213962590
TEST=manual testing with crrev.com/c/3394436
TEST=check ARCVM balloon still works
Change-Id: Idd606b90550c544ce5bea085f62ac35979679d71
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3394442
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: David Stevens <stevensd@chromium.org>
Manatee doesn't support the guest accessing pages in the balloon, since
that would violate the strict its strict memory accounting, so add an
option to skip setting the deflate-on-oom flag.
However, without deflate-on-oom, the Linux driver normally modifies
MemTotal when inflating/deflating the balloon. To avoid that, this
change adds support for the new responsive-device flag proposed in [1].
[1] https://lists.oasis-open.org/archives/virtio-comment/202201/msg00139.html
BUG=b:214864326
TEST=check ARCVM balloon still works
TEST=manual testing with crrev.com/c/3394436
Change-Id: Iabc8352ee30e1b4a240fa3cad8f3b48ba53699a0
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3471335
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: David Stevens <stevensd@chromium.org>
Implement event queue that was recently proposed upstream [1]. The puff
failure event will be used in a followup CL. The pressure event is
currently ignored. Figuring out how to use it will be done later.
[1] https://lists.oasis-open.org/archives/virtio-comment/202201/msg00139.html
BUG=b:213962590,b:216214118
TEST=check ARCVM balloon still works
Change-Id: Ie1990505da8eda1358f10f24ca3c2b6196303184
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3471334
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: David Stevens <stevensd@chromium.org>
The compiler was warning about a missing `dyn` on the impl block for
PciDevice, which only contained supports_iommu():
warning: trait objects without an explicit `dyn` are deprecated
We could add the `dyn` to fix it, but it seems cleaner to just move the
definition into the VirtioPciDevice impl's existing supports_iommu
function.
Additionally fix up a few clippy warnings about open-coded instances of
map and unnecessary references.
BUG=None
TEST=cargo build # completes without warnings
TEST=tools/presubmit
Fixes: 055b81b295 ("VIRTIO_F_ACCESS_PLATFORM support in virtio-iommu")
Change-Id: I7c923d1663d4f8c958a3c79619a06ab04e1e00ae
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3498843
Reviewed-by: Anton Romanov <romanton@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
This reverts commit d2d66bc0a4.
Reason for revert: It turns out that adding the first page to the pool
of memory managed by the MMIO allocator has undesired consequences
since crosvm will actually use it for MMIO regions. The first page
has special semantics in other code though, and thus we get stray
accesses to this region, with hard-to-predict consequences.
BUG=b:188011323
TEST=cq
Original change's description:
> system_allocator: allow more than one region to be in the pool
>
> Allows crosvm-direct to have 0-0xfff regions to be mapped.
>
> limitations: Only the first regions gets reflected in the
> pool_base/pool_size.
>
> BUG=b:188011323
> BUG=b:184815519
> TEST=build
>
> Change-Id: I9da3cb2b8d5611068f9323d6ebf62f44162838b4
> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3450017
> Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
> Tested-by: kokoro <noreply+kokoro@google.com>
> Commit-Queue: Junichi Uekawa <uekawa@chromium.org>
Bug: b:188011323
Bug: b:184815519
Change-Id: Ib42b3007662a7a49ad876b83a01f1bb88d09d5f7
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3497136
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Mattias Nissler <mnissler@chromium.org>
Commit-Queue: Mattias Nissler <mnissler@chromium.org>
When a client sends 0-sized data, the device regards that the client
closed the connection and will exit properly.
BUG=b:219674197
TEST=check if no error is shown when a vhost-user blk vmm disconnects
Change-Id: Icd84fb241c39b6dc54a8af41a068a6dd95ce4c2b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3468235
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
With VIRTIO_F_ACCESS_PLATFORM, virtqueues and desc chains of a
virtual device will receive IO virtual addresses. Mappings from
IOVA to GPA will be sent to virtio-iommu. `IpcMemoryMapper` is used
by the virtio device to get the translated addresses from the
virtio-iommu in another process.
Memory blocks with contiguous IOVA but discontinguous GPAs are
supported.
The only way to enable this new path is to hardcode the flag in
the features of each device. The flag should be automatically
for every virtio-vhost-user device in the future. It seems
questionable to add a per device command line option just for
testing.
BUG=b:215307964
TEST=cargo test/block device with VIRTIO_F_ACCESS_PLATFORM enabled
Change-Id: I9a89acf4f38d52816adad34c0dbff043677bebac
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3347309
Reviewed-by: David Stevens <stevensd@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Woody Chow <woodychow@google.com>
pvpanic is a simulated device through which a guest panic event could be
sent to the VMM. More details here:
https://github.com/qemu/qemu/blob/master/docs/specs/pvpanic.txt
Implement pvpanic device emulation and its pci interface.
BUG=None
TEST=Built crosvm. Ran a minimal vm to crash and verified that crosvm
receives the panic event. cargo test on devices.
Change-Id: I766fcc08f07760ad5f64f440a577705efd82e32a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3480575
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Vineeth Pillai <vineethrp@google.com>
On Manatee, all the pcie endpoint device are passed through into guest
and all the physical pcie root port are linked to virtual pcie root
port, if one pcie endpoint is connected to physical pcie rp statically
on host, this pcie endpoint should be connected to a virtual pcie rp in
guest statically. But current crosvm pcie could support hotplug device
only, it couldn't support connection device statically at boot time.
This commit add such support. if virtual pcie rp is used to
connect device statically, it won't use slot and won't have hotplug
capability.
BUG=b:185084350
TEST=On Byra-manatee, link all the physical pcie rp to virtual pcie
rp, then check NVME/SD/WIFI's function in CrOS, these devices are
connected to pcie RP on host directly.
Change-Id: Ie277c749da3c2020ad7361bf9ffa0271fb8f415d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3464512
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Since we'll be putting all PCI devices on non-root buses behind virtual
PCI-E root ports, MMIO BARs in such devices must be inside the forward
windows of their root ports. This presents additional requirements for
their MMIO BAR allocation:
1. All non-prefetchable BARs must be inside the same 32-bit MMIO window
2. All prefetchable BARs must be inside the same MMIO window, but
different than the non-prefetchable MMIO window
3. Both windows must be 1MB-aligned
4. No other PCI devices should occupy MMIO space in these windows
Allocate the entire window from the system resource allocator to prevent
any space within the window from being used elsewhere. To maximize
memory space efficiency, use VfioResourceAllocator for BAR allocation.
BUG=b:185084350
TEST=passthrough a vfio-pci device with bus_number > 0 and static connet it
behind a pcie root port, then check pcie RP and vfio-pci device function in
guest.
Change-Id: Ic9865afc48eb3ff9fa475dbcfdf90642b012980c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3166888
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Introduce the struct BarRange{addr, size, prefetchable} to indicate the
return of allocate_io|device_bars. So it is readable and easy to use.
BUG=b:185084350
TEST=boot Linux kernel and check dmesg
Change-Id: I0073f20401816f60c131bf15a9bc196e5fcba6d0
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3455126
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Make VfioMsixAllocator a generic resource allocator.
BUG=b:185084350
TEST=boot Linux kernel and check dmesg
Change-Id: I4a301d6829600a90fe0ddef4ccccbd4c8f511208
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3166887
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Split the logic in allocate_io_bars() into several parts in preparation
for the upcoming changes:
- collect_bars(): gather BAR information
- configure_barmem(): configure an MMIO BAR
- allocate_barmem(): main logic for MMIO BAR allocation
BUG=b:185084350
TEST=boot Linux kernel and check dmesg
Change-Id: I7eca48b16081dfd180ce4616239f568355e5031f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3166886
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
The MemoryMapping API has changed and these tests are not run by
default, which prevented us from catching this.
BUG=b:213149154
TEST=with crrev.com/c/3026355: cargo test --features "video-decoder,ffmpeg" -p devices virtio::video
Change-Id: I79a07d5a60c520d16190dd220b9a0f7501565e2c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3493533
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
The base version of MemoryMapping does not have the from_fd_offset
function. Use base::MemoryMappingBuilder and MemoryMappingBuilderUnix to
get the same functionality without depending directly on sys_util.
Fixes the build with virtio video features enabled.
BUG=b:213149154
TEST=emerge-hatch crosvm
Fixes: 45f1a419d4 ("Make crates depend on base instead of sys_util")
Change-Id: I8924d2334ae3d3ef489114b17071143871d1424d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3490743
Reviewed-by: Vikram Auradkar <auradkar@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
When the client clears the output queue, it regains ownership of all the
currently queued output buffers. Unless the backend is made aware of
this, it will keep believing that it owns these buffers and may throw an
error when they are submitted again, so add a backend op to signal the
backend it should release all its output buffers.
The VDA backend does not make any such check, so its implementation can
be a no-op.
BUG=b:169295147
TEST=Android Youtube can play videos on Hatch.
Change-Id: Ia7d08e2499818e02a2bf56618852acdaee0d6d28
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3143585
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Backend errors are a single variant of VideoError and not matched by
themselves, so let's use anyhow instead of our own boxed error.
BUG=b:169295147
BUG=b:214478588
TEST=cargo build --features "video-decoder,video-encoder,libvda"
Change-Id: If5c056e8f8b6dfc0aec607d515db920bf1b83524
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3482935
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
As we make progress on upstreaming sys_util, we do not want more
dependencies on sys_util added. This check helps in that cause.
With this change only files that are inside common can depend directly
on sys_util.
Test: python3 ./tools/impl/check_code_hygiene.py common/sys_util_core
Bug: b:213149154
Change-Id: I57a8cb9189d3263a4031338b302cb27da799f4de
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3473344
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Auto-Submit: Vikram Auradkar <auradkar@google.com>
Commit-Queue: Vikram Auradkar <auradkar@google.com>
PciAddress is not really related to pci_root. Split it out so that it is
easier to find and so it can have its own tests nearby.
No code changes.
BUG=None
TEST=cargo build
Change-Id: I2bdad518de76587506593292cf0fbdb6b7066c1e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3475439
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Slot capabilities are only implemented if the root port is used for
hotplug. Allow PcieRootPort to be created with the option to not
implement slot capabilities and make all slot operations noops in that
case.
BUG=b:185084350
TEST=boot Linux kernel and check dmesg
Change-Id: I31410fc3e28d9d7cdc55edadcdb5e7dde796c5ce
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3166884
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
to support contiguous iova but discontiguous gpa memory block.
`MemRegion` also contains `perm`. `perm` allows R/W permission
enforcement.
The function will be used in virtio-iommu (CL coming soon).
BUG=b:215307964
TEST=cargo test
Change-Id: I37975480321a07741bfea232e9e6234cf0b93614
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3450022
Reviewed-by: David Stevens <stevensd@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Woody Chow <woodychow@google.com>
Use the existing register_memory() function that does the same thing as
the open-coded registration request.
BUG=None
TEST=tools/presubmit
Change-Id: I62956c2b4ceb288f7b76a4e85c27e288c496c73b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3470538
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
This reverts commit 73072d6d16.
Reason for revert: broke ARCVM GTS tests
Original change's description:
> virtio: video: encoder: set frame rate only if successfully changed
>
> Encoders Stream's frame rate was updated before a request was made.
> This could cause hypervisor to report incorrect frame rate to guest and other
> invalid behaviour if the request failed.
>
> This CL changes the order in which frame rate is updated. First a
> request is made, and then if successful, the frame rate is updated in
> the stream structure.
>
> BUG=b:160440787
> BUG=b:161774071
> TEST=v4l2-compliance -d /dev/video1
> TEST=v4l2-ctl -d 1 --set-fmt-video-out
> width=1280,height=1280,pixelformat=NV12 \
> --set-output-parm 10 --get-output-parm
> TEST=tast run eve arc.Video*
>
> Change-Id: I11a93d6d6338829ee0622f40f9b544a4ef2a69dc
> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3425362
> Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
> Tested-by: kokoro <noreply+kokoro@google.com>
> Commit-Queue: Marcin Wojtas <mwojtas@google.com>
BUG=b:160440787,b:161774071,b:220101996
TEST=GtsMediaTestCases com.google.android.media.gts.RtcVideoCodecTest#testDynamicFramerateChangeVp8
Change-Id: Ic10d93f0d3b29bef623ef3d9e3ff00d524a66ebd
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3474731
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Shao-Chuan Lee <shaochuan@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Device can be started with
crosvm device console --vfio <PCI ID>
BUG=b:213531730
TEST=console is usable from a sibling guest when using VVU.
Change-Id: Id19ea8d8d1e11f29a024a30b09622513ad8b172f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3429063
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Run tests for sys_util_core, poll_token_derive and balloon_control on
windows.
Using dotfiles to disable/serialize test runs of a subset of crates does
not work well with third party crates as it forces us to commit the dot
file to the crate.
The patch modifies and uses the script that runs linux tests.
This patch also allows us to
- build/test child crate even if parent crate has disabled build/test.
- avoid building crosvm if it is not explicitly specified.
RIP short lived .windows_build_test_skip. You allowed us to run noop
kokoro tests.
Test: py .\tools\impl\test_runner.py --arch x86_64
Bug: b:215610772
Change-Id: Icc6d04ffd7c0c33d4f60aeac16fc7d23881c387d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3459809
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Vikram Auradkar <auradkar@google.com>
io ports is a 16 bit thing, check that it is actually 16 bits and fix
the parameters.
BUG=None
TEST=read intel SDM, run crosvm test
Change-Id: I50b6d5593b0699317ac2f852836208a46240714b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3470601
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Junichi Uekawa <uekawa@chromium.org>
The driver can send VIRTIO_MSI_NO_VECTOR as a MSI notification vector in
order to indicate this vector should not be used. We are not using this
currently but the spec mentions it.
BUG=b:194136484
TEST=VVU-enabled console device works properly.
Change-Id: I7023926b4acc8c46c193af6a4c3fb5b6d2383096
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3467299
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Currently the proxy code aborts if the sibling did not set a MSI vector
for each of the 16 potentially supported queues. This prevents devices
that use less queues than that (like console, which uses 2) to even
start.
Fix this by putting the MSI vector into an option, and returning an
error at runtime if an unset interrupt is ever signaled.
BUG=b:194136484
BUG=b:213531730
TEST=VVU-enabled console device can start.
Change-Id: I985870c23365ff97fc97553206d6b1a2bfdf8b06
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3467298
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
`process_doorbell_message` receives a usize, so make sure that
`write_bar_doorbell` sends an index of the same type. The
current code is only working on 64-bit machines where both types have
the same size by accident.
BUG=b:194136484
TEST=VVU-enabled console device works properly.
Change-Id: Idf01d4846edcf9bcc5c2d6c36dbc739c81f363e6
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3467296
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
As specified by the VVU spec, the adress of a doorbell within a BAR is
cap.offset doorbell_idx * doorbell_off_multiplier
The `cap.offset` is properly accounted for, but not the multiplier,
resulting in a invalid doorbell being notified if the write offset is
bigger than 0.
BUG=b:194136484
BUG=b:213531730
TEST=VVU-enabled console device works properly.
Change-Id: I96a2b67d905d2453017cdd230b2dda21345d236a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3467295
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
This variable can be passed as part of the backend structure.
BUG=None
TEST=cargo build
Change-Id: Ic279af17e67ffe31baae5db5cb2b3c5a511b0c13
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3451758
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
This variable can be passed as part of the backend structure.
BUG=None
TEST=cargo build
Change-Id: I085761711fe3d214217541e91bb23f00eafc67c5
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3451757
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
This variable can be passed as part of the backend structure.
BUG=None
TEST=cargo build
Change-Id: Ic41c9dbcea780e0251743bc63d7935969fa4550b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3451756
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
This variable can be passed as part of the backend structure.
BUG=None
TEST=cargo build
Change-Id: Ic2f5987110acb54bd5486bd63924d052bded17cc
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3451755
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
This variable can be passed as part of the backend structure.
BUG=None
TEST=cargo build
Change-Id: Id8f905cc87de261a1a547da66fb93dafc1b7686d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3451754
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
This variable can be passed as part of the backend structure.
BUG=None
TEST=cargo build
Change-Id: Ib849a1479c8559b9482b0a96e97e3452a9519cd8
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3450028
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Morg <morg@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
This variable can be passed as part of the backend structure.
BUG=None
TEST=cargo build
Change-Id: I3c1f6e04417ea2e6c8b2d4d662829cf24b353fdf
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3450027
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Some tests had unrealistic values, fix them in case I want to add some
validation in the future.
BUG=None
TEST=None
Change-Id: I126c83b4ac91442f87aae8be9e84565a7a3d98a2
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3446980
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Noah Gold <nkgold@google.com>
Commit-Queue: Junichi Uekawa <uekawa@chromium.org>
The patch prepares backend.rs and connection.rs to be platform
independent by
- depending on base instead on sys_util
- using base::Event over sys_util::EventFd
- replacing RawFd usage with RawDescriptor and derivatives
To keep the noise low, the patch
- aliases structs/traits (Event as EventFd)
- does not rename variables (say from fd to rd).
Note: With this patch the crate/files are not completely platform
independent.
Test: Built, clippy and fmt
Bug: b:213151429
Change-Id: Ib57528ef1a951c3d083cf345c878ec1417b7ce3e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3460428
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Vikram Auradkar <auradkar@google.com>
Increase readability by reducing nesting and function length.
Also, remove Option from VirtioPciDevice.mem as it cannot be
None.
BUG=b:215307964
TEST=cargo test
Change-Id: I66d57d5205a59a507433d71de71ca58a98cfeb6c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3460790
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Woody Chow <woodychow@google.com>
This change adds the main process tube to the list of fds that need to
be kept open after the proxy device process forks.
BUG=b:194136484
TEST=Run device VM without --disable-sandbox.
Change-Id: I41be8ef68cf5925b2f677944998cf2ae1c20fdb8
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3435165
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Abhishek Bhardwaj <abhishekbh@chromium.org>
This change adds a new num_interrupts API to the Virtio device trait.
This is because for the proxy device the number of interrupts is
different from the number of its own queues. It also includes the queues
of the device being proxied i.e. block, net, etc..
BUG=b:194136484
TEST=Run "head /dev/vdb;mount /dev/vdb /mnt;echo "1" >> /mnt/1.txt" in
the sibling VM.
Change-Id: I0c3b3a85772c1364660d5570ad86bbaecfb0faf5
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3309202
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Abhishek Bhardwaj <abhishekbh@chromium.org>
This change implements the Doorbell bar logic for the VVU proxy device.
This includes writing to the call event corresponding to vring specified
by the doorbell write.
BUG=b:194136484
TEST=Test with sibling VM with Vhost master connecting to a device VM.
Change-Id: I1e97c171ca8336151facd19ebe8107b092db8d42
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3301861
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Abhishek Bhardwaj <abhishekbh@chromium.org>
This change adds another metadata size check to the set_mem_table
function.
BUG=b:194136484
TEST=Test with sibling VM with Vhost master connecting to a device VM.
Change-Id: I561af017a35b2fa7ac81b9bcb1af9c6fcf63ba1f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3462647
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Abhishek Bhardwaj <abhishekbh@chromium.org>
This change implements the SET_VRING_KICK and SET_VRING_CALL VVU
message. This involves storing both the call and kick events in the
proxy device. Furthermore, this change monitors the kick event and
injects the corresponding interrupt into the guest.
BUG=b:194136484
TEST=Test with sibling VM with Vhost master connecting to a device VM.
Change-Id: I8b400a01c1e82ff7d4fbdbc8a6d7926fef3511dd
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3301860
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Abhishek Bhardwaj <abhishekbh@chromium.org>
Allows crosvm-direct to have 0-0xfff regions to be mapped.
limitations: Only the first regions gets reflected in the
pool_base/pool_size.
BUG=b:188011323
BUG=b:184815519
TEST=build
Change-Id: I9da3cb2b8d5611068f9323d6ebf62f44162838b4
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3450017
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Junichi Uekawa <uekawa@chromium.org>
The patch prepares backend.rs and connection.rs to be platform
independent by
- depending on base instead on sys_util
- using base::Event over sys_util::EventFd
- replacing RawFd usage with RawDescriptor and derivatives
To keep the noise low, the patch
- aliases structs/traits (Event as EventFd)
- does not rename variables (say from fd to rd).
Note: With this patch the crate/files are not completely platform
independent.
Test: Built, clippy and fmt
Bug: b:213151429
Change-Id: Id93d4a70db627578e6577017f8ca4d69f892d69a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3460427
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Vikram Auradkar <auradkar@google.com>
Support running the vsock device backend over vvu instead of a unix
doman socket.
BUG=b:213530766
TEST=Use nc-vsock to transfer data between device vm <-> sibling vm
Change-Id: I065ebf8d0bc306fe707d843cfabc2bf600b2e8f4
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3369506
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
The previous limit was incorrect, as we are using SPI (Shared Peripheral
Interrupt) type interrupt sources for PCI devices, but the limit was
based on the total number of SPI + PPI interrupts.
This fixes interrupt delivery when many PCI devices are used on arm
platforms.
BUG=b:218757314
TEST=Run crosvm with 32+ block devices on trogdor
Change-Id: Ie89bc5b7115117d8acaca30ff758b9342940b450
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3453119
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
In preparation to allow multiple low memory regions to be passed on, I wanted to
make initialization simpler.
Introduce `MemRegion` struct instead of tuple to help me understand it is a base
and size.
BUG=b:188011323
TEST=build
Change-Id: Ie8b54354a25c478d5ad0a0185b7e07d28840dd87
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3439666
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Junichi Uekawa <uekawa@chromium.org>
crrev.com/c/3205229 introduced an associated type
`VhostUserBackend::Doorbell` to allow support different types for
vhost-user and vvu.
However, we finally concluded having it as an enum would be better
because it allows us to decide which vhost-user or vvu is used at
run-time so that we can share more code between vhost-user and vvu.
So this CL replaces the associated type with an enum value.
BUG=b:194137301
TEST=build
Change-Id: I60d7080e5d3bcd397ab70c8f9b83c7d6cd08bb92
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3353057
Reviewed-by: Chirantan Ekbote
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Enable VVU feature unconditionally.
Since kokoro will start checking VVU code from this CL, clippy errors
are fixed.
In addition, the time limit of kokoro unit testing needed to be
increased because some time-consuming unit tests will start running on
aarch64 QEMU, which is really slow.
BUG=none
TEST=kokoro
Change-Id: I67437c060ff5ba9f690dcfc6e5c3dd155b95a785
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3450014
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
and BasicMemoryMapper impl. This will be used for
VIRTIO_F_IOMMU_PLATFORM support in virtio-iommu.
BUG=b:215307964
TEST=cargo test/block device with VIRTIO_F_ACCESS_PLATFORM
with crrev.com/c/3347309 (to be submitted)
Change-Id: Iadd964556edf5b95aa00b542b4bde5a997756090
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3334331
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: David Stevens <stevensd@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Woody Chow <woodychow@google.com>
Add a safe helper function to call `VBFIO_DEVICE_GET_INFO` ioctl, which
will be used from VVU later
BUG=b:194136484
TEST=build
Change-Id: Ia3b797fba7cd77fc7698230e88a94e619485eaca
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3446522
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
This will allow reusing `MsixCap` for virtio-vhost-user in the later
CLs.
BUG=b:194136484
TEST=cargo test
Change-Id: I38bced958d42ce7e3192a54564628c9b559c4269
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3446521
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
When virtual pcie root port RTD3 is enabled, it will enter into suspend if child device
isn't exist. Pcie hp driver disable hotplug interrupt once it enters into suspend state,
so hotplug interrupt couldn't be injected into guest if pcie RP is in suspend state. In
such case a PME will be injected into CrOS to wakeup itself first, another hotplug event
will be injected after this PME.
BUG=b:185084350
TEST=Hotplug a vfio-pci device into CrOS with virtual RP RTD3 enabled
Change-Id: I96f8ac6ba27072f6cfbc01df00c0a48f2d92a7e5
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3423463
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
In order to link virtual pcie root port's power status with physical
pcie root port, power control capability should be added to let guest
enable RTD3 for virtual pcie root port.
BUG=b:185084350
TEST=check virtual pcie root port's RTD3 status in CrOS
Change-Id: I25e36b845b7ec198f995e82dda7850e4a1af0d9e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3423462
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
When pcie-root-port parameter is used to link virtual pcie RP with
physical RP, they should have the same bridge window size.
BUG=b:185084350
TEST=Boot CrOS with pcie-root-port parameter in ManaTEE and check
bridge window size in CrOS
Change-Id: I7864b37ecd61af52b470701803e746080f3a9025
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3423461
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
On ManaTEE, each physical pcie root port has a virtual pcie root port in
CrOS, this commit links virtual RP to physical RP. The following virtual
RP's config registers are from physical:
--devie ID
--device type
--bridge bus range
BUG=b:185084350
TEST=Check virtual pcie RP config registers in ManaTEE CrOS
Change-Id: Ia38a0f2417331d562dbb305433c68a3bee678bde
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3423459
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Currently bridge's PciAddress is allocated from system bus allocator,
but when virtual pcie root port is linked to physical pcie root port,
its PciAddress should be same as physical pcie RP, so thid commit let
bridge get its PciAddress from the backend pcie RP device, this is
convenient for later pcie root port.
This commit doesn't change function.
BUG=b:185084350
TEST=tools/presubmit
Change-Id: I2b81f6447898bd76758569095aa48f3daa2b0dcc
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3423458
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Currently pci bridge's bus range is managed in pci bridge structure, but
when virtual pcie root port is linked to physical pcie root port, the bus
range of virtual pcie RP should be same as physical pcie RP, so this commit
let bridge get its bus range from the backend pcie root port device, this
is convenient for later physcial pcie root port.
This commit doesn't change function.
BUG=b:185084350
TEST=tools/presubmit
Change-Id: I80c54365d6def455e32e7934e7216c677902450d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3423457
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
As more function are adding into pcie.rs, one file wil be larger. This commit
split pcie.rs into three files:
pci_bridge.rs: handle pci bridge device and implement PciDevice trait
pcie_device:rs: define PcieDevice trait and PcieCap
pcie_rp.rs: virtual pcie root port emulation, implement PcieDevice trait and
HotPlugBus trait
This commit doesn't change function.
BUG=b:185084350
TEST=tools/presubmit
Change-Id: I4ab16f35e78a9d084a7a47d91a7fcf37e9f3e91d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3423456
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
An async IPC translation request handler will be added for
b/215307964. This CL is preliminary.
BUG=b:215307964
TEST=cargo test/block device with VIRTIO_F_ACCESS_PLATFORM
with crrev.com/c/3347309 (to be submitted)
Change-Id: I1ce7b1c53e8efb3ae8652caba02693fee77646b1
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3382499
Reviewed-by: David Stevens <stevensd@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Woody Chow <woodychow@google.com>
The `run_until` method of the executor returns a Result<Result<..>>,
where the outer result signals errors within the async executor, and the
inner result is the actual result of the passed future.
The current error handling completely ignores this inner error, making
"crosvm device" exit silently if we e.g. specify a socket that already
exists.
Fix this by explicitly returning outer errors if they exist, and
returning the inner anyhow::Result as-is so both levels of errors are
properly reported.
BUG=None
TEST=cargo build
TEST=console device properly reports and error if its socket file
already exists.
Change-Id: I7d091bd7b0d66a07c6f340ebf9e395d0dab2c212
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3439668
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Anton Romanov <romanton@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Encoders Stream's frame rate was updated before a request was made.
This could cause hypervisor to report incorrect frame rate to guest and other
invalid behaviour if the request failed.
This CL changes the order in which frame rate is updated. First a
request is made, and then if successful, the frame rate is updated in
the stream structure.
BUG=b:160440787
BUG=b:161774071
TEST=v4l2-compliance -d /dev/video1
TEST=v4l2-ctl -d 1 --set-fmt-video-out
width=1280,height=1280,pixelformat=NV12 \
--set-output-parm 10 --get-output-parm
TEST=tast run eve arc.Video*
Change-Id: I11a93d6d6338829ee0622f40f9b544a4ef2a69dc
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3425362
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Marcin Wojtas <mwojtas@google.com>
Prior to this change, frame rate wasn't modified in video encoder input
and output params. This resulted in hypervisor reporting to guest a frame
rate equal to zero at all time. This is inconsistent with actual frame rate.
Futhermore frame rate equal to zero causes v4l2-compliance to fail.
This CL ensures that frame rate is stored in input and output stream
params and that its value is reported correctly to the guest. With this
change we remove field_rate from Stream struct to avoid storing the same
value in 3 saperate places instead 2.
BUG=b:160440787
BUG=b:161774071
TEST=v4l2-compliance -d /dev/video1
TEST=v4l2-ctl -d 1 --set-fmt-video-out width=1280,height=1280,pixelformat=NV12 \
--set-output-parm 10 --get-output-parm
TEST=tast run eve arc.Video*
Change-Id: Iff76a923d5f337db86fe67bfc77b13cd6bf58edf
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3417310
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Marcin Wojtas <mwojtas@google.com>
Till this point, frame size was stored in either input params or output
params depending on the device. This caused to virtio-video to report
zerod width and height on one buffer end, which caused v4l2-compliance
to fail.
This CL makes encoder and decoder store frame sizes in both params.
BUG=b:160440787
BUG=b:161774071
TEST=v4l2-compliance -d /dev/video0
TEST=v4l2-compliance -d /dev/video1
TEST=tast run eve arc.Video*
Change-Id: I77d8ab4c0ed1d0a877ed090b169a922606dcee70
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3412775
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Marcin Wojtas <mwojtas@google.com>
Previously most decoder initial parameters were set to zero due to use
of Default::default(). This caused decoder to start with incorrect values,
and led to v4l2-compliance failing.
This CL sets initial decoder parameters to artificially chosen values in
order to comply with v4l2-compliance.
BUG=b:160440787
TEST=v4l2-compliance -d /dev/video0
TEST=tast run eve arc.Video*
Change-Id: I283473d856e94087f039bc8f60c978c384f7f22c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3402215
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Marcin Wojtas <mwojtas@google.com>
Before this CL, both encoder and decoder had separate code which
computed plane formats for given format.
This CL removes code duplication, by introducing PlaneFormat::get_plane_layout,
which returns vector of plane formats if given format is supported. At
this point only NV12 is supported.
BUG=b:160440787
BUG=b:161774071
TEST=v4l2-compliance -d /dev/video0
TEST=v4l2-compliance -d /dev/video1
TEST=tast run eve arc.Video*
Change-Id: I427346d7e286a2e52aa4cbdc6e042a996812f3b1
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3425360
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Marcin Wojtas <mwojtas@google.com>
We used to bail early if an error happened while we run the console
device, leaving the terminal in raw mode.
BUG=None
TEST=cargo build
Change-Id: I3dc4a681f736246548d1cc7b7eab0bfd429587be
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3439667
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
New iommu backend to handle virtio devices will be added.
This CL makes organizing the code in the future easier.
BUG=b:202151642
TEST=cargo test/block device with VIRTIO_F_ACCESS_PLATFORM
with crrev.com/c/3347309 (to be submitted)
Change-Id: Ib6ac9687298b1d75f151aea7c07963757f8dad87
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3305966
Reviewed-by: David Stevens <stevensd@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Woody Chow <woodychow@google.com>
Implement UserQueue struct which represents a virtqueue for a VFIO
driver.
Unlike the existing `virtio::Queue` which provides methods for devices
to handle virtqueues, this struct provides methods for drivers.
This will be used by virtio-vhost-user VFIO driver which run in the
guest userspace.
This implementation is hidden behind the "vvu" feature.
BUG=b:194137301
TEST=cargo test --features=vvu in devices
Change-Id: I3813448279b2f6576c0eb295a742728cef28a9b5
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3206630
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Separating the render server from virtio GPU code will allow us to start
it when starting plugin-based VMs.
BUG=None
TEST=./tools/presubmit
Change-Id: If31780effddfd2b3f21b6b6cbc0c9630931a3c9b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3418733
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dmitry Torokhov <dtor@chromium.org>
This change implements the SET_MEM_TABLE and lays the foundation of the
SET_VRING_CALL VVU message. It mmaps memory based on the the parameters
sent over the message.
BUG=b:194136484
TEST=Test with sibling VM with Vhost master connecting to a device VM.
Change-Id: I34398e6bad633ac9f72c5c1859c43c7c90c9ea25
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3301859
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Abhishek Bhardwaj <abhishekbh@chromium.org>
Auto-Submit: Abhishek Bhardwaj <abhishekbh@chromium.org>
Apply usb configuration even when configuration is not changed. When
Android sets usb configuration, it expects the device connection gets reset.
This change will pass CTS verifer USB devices tests which try to
observe device connection and reconnection after set unchanged usb
configuration.
BUG=b:123374026
TEST= Run cts verifer USB device tests in ARCVM.
TEST=lsusb in crostini. device shows.
Change-Id: I5856d1173a3ea1a65c6fa205cb9facd407706a6c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3413815
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Auto-Submit: Long Cheng <lgcheng@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Long Cheng <lgcheng@google.com>
It's a simple enum, so it should be Copy.
TEST=tools/dev_container tools/run_tests
TEST=tools/dev_container tools/run_tests --target=vm:aarch64
Change-Id: Ieeacedb10fa6a93d6cdd9878097c66aa936f8e30
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3420329
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Andrew Walbran <qwandor@google.com>
Add a crate containing an API for controlling the balloon. This is done
by reusing the API between the control socket and the balloon device.
BUG=b:213962590
TEST=compiles
Change-Id: I5d89d5ebee55162d28ba45ca2c49b7083561b916
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3394440
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: David Stevens <stevensd@chromium.org>
Fix a few compilation warnings in our tests:
* The PCI device had an unused argument without a leading underscore in
the name ;
* The virtio queue is dereferencing null pointers, which is UB albeit
technically ok in this case (bindgen generates similar tests too [1]).
[1] https://github.com/rust-lang/rust-bindgen/issues/1651
BUG=None
TEST=cargo test in devices/ does not show these warnings anymore.
Change-Id: Id272b5381f80bb72d96839a5a6da8bb0c644502d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3418623
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
The patch also adds files to skip building and testing crates on
windows. When we run
```
tools/windows/build_test.py --skip_file_name .windows_build_test_skip
```
the build/test succeeds without actually doing anything as build/test
for all crates is skipped by creating '.windows_build_test_skip'.
Bug: 213170957
Test: Ran script on downstream repo
Change-Id: Iebd2cea463ee722be4feaed88229e1fb5e9fd6c5
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3417918
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Vikram Auradkar <auradkar@google.com>
The tool is added to ./tools/fmt which will be called during
./tools/presubmit as well as by Kokoro during testing.
This requires a new dev container version to bundle the mdformat
tool in the container.
Note: mdformat does not have any IDE integrations, but the prettier
plugin with prose-wrap enabled and a line length of 100 provides
almost identical results.
BUG=None
TEST=./tools/fmt --check
Change-Id: I0ae5659eff8555df7c85c70e62095a1e116b98da
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3416098
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Add an init-mem parameter that limits how much memory the VM can use on
startup. If set, the balloon is inflated on startup to (mem - init-mem).
BUG=b:213962590
TEST=set param and verify balloon inflates on startup
Change-Id: I920bf9cfa26081ee544219406f8cf9827ff84bfa
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3394439
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: David Stevens <stevensd@chromium.org>
The picture buffer size was computed from the size of the visible
rectangle, which is potentially incorrect: if the origin of the visible
rectangle is not (0, 0) then the buffer is going to be larger.
Fix this by using the provided coded width and height, which correspond
to the actual size of the buffer and not just its visible area.
BUG=b:161774071
TEST=Android Youtube decodes properly on zork-arc-r.
Change-Id: I80e15248f41d6202190456d2ab61f8f50d3b6ebb
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3412457
Reviewed-by: Chih-Yu Huang <akahuang@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: David Staessens <dstaessens@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
The pages which are frequently used by the VM are likely not to be
unpinned. So an optimization is to skip the unpin scan for those pages
in the LRU unpin policy. The unpin_gen_threshold defines a threshold
number that, if a page cannot be unpinned in a period of
(unpin_gen_threshold* unpin_interval) seconds, then this page will be
marked as inactive. Those inactive pages will be scanned every
(unpin_gen_threshold* unpin_interval) seconds if there is no enough
active pages to unpin.
BUG=b:188481989
TEST=Boot a VM with coiommu lru unpin policy + pass through devices.
Change-Id: Ie020173097b6f4f925cafc121a802243ef65f165
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3292941
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Stevens <stevensd@chromium.org>
Unpin is handled indepently with the coiommu frontend driver. To
support the DTT shrinker happened in coiommu, it needs a way to
park the unpin thread for a while in case unpin is also accessing
the DTT. When the shrink is done, frontend can unpark to make unpin
thread work again.
BUG=b:188481989
TEST=Boot a VM with coiommu lru unpin policy + pass through devices.
In VM, use command #echo 2 > /proc/sys/vm/drop_caches to trigger
shrink.
Change-Id: Icea6aee6424f09339b549eb2735c73551a87a505
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3292940
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Deactivate command is used when the CoIOMMU driver in the guest
is failed to probe, or CoIOMMU device is removed by the guest.
But these are not expected to happen. Once this happened, the
guest won't be functional as all the pass-through devices on top
of CoIOMMU will not work. So in the backend side, just panic when
receive such command.
BUG=b:188481989
TEST=Boot a VM with coiommu and remove it in the guest.
Change-Id: I912c71d80e6cbd02bf7edc6bfb30ef11051dc490
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3292939
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Stevens <stevensd@chromium.org>
Add a crosvm parameter to allow user to sepcify the coiommu unpin
policy. Besides unpin the pages when balloon inflate, coiommu also
supports to periodically unpin with a LRU policy.
The usage is like this:
"--coiommu unpin_policy=lru,unpin_interval=10,unpin_limit=8192"
which means to use LRU unpin policy with unpin interval is 10 seconds
and the unpin count limit for each cycle is 8192 pages.
Without specify the parameter, coiommu will use the default
configuration which is to turn off the periodically unpin.
BUG=b:188481989
TEST=Boot a VM with coiommu lru unpin policy + pass through devices.
Change-Id: I10414cc6b2520b804685450dfd1560cfe49455a7
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3292938
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Stevens <stevensd@chromium.org>
LRU unpin policy is an internal unpin policy which is triggered by
a timer. This policy can be used when there is no external balloon
unpin request.
BUG=b:188481989
TEST=Boot a VM with coiommu enabled + pass through devices.
Change-Id: Icb6e19073cb668fa954aec97e02be77f1b8f6a04
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3292937
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Stevens <stevensd@chromium.org>
Put the VFIO pass-through devices and coIOMMU creating earlier
than the virtio device so that when creating virtio-balloon
it can use the tube from coIOMMU to send the unpining request
when processing the inflate.
BUG=b:188481989
TEST=Boot a VM with Network device pass through w/ coiommu, and do
the iperf test. Then perform balloon inflate/deflate.
Change-Id: If3ff9b3b0293ce49a39498a18feae1d697523f92
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3292936
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Stevens <stevensd@chromium.org>
Coiommu can be enabled through the command line. E.g.
To enable coiommu for a VFIO pass-through device:
--vfio=/sys/bus/pci/devices/0000:00:02.0,iommu=coiommu
BUG=b:188481989
TEST=Boot a VM with a VFIO pass through device w/ coiommu
TEST=Boot a VM with a VFIO pass through device w/o coiommu
Change-Id: Ica6145d7bc6a4c398f0fc10899f8ee24138615c4
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3292934
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: David Stevens <stevensd@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
When balloon to do inflate to release some memory to hypervisor, such
memory should also be unpinned by the component(e.g. coiommu) which
has pinned these memory. This tube will be used by balloon to send
the unpin request to the components(e.g. coiommu) to do the unpin
before releasing the memory.
BUG=b:188481989
TEST=Boot a VM and check balloon inflate/deflate
Change-Id: I06aa8bd8c11deeac9f133adbefa6442cf1b722de
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3292932
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Stevens <stevensd@chromium.org>
The memory pinned by coiommu cannot be release to hypervisor unless it
is unpinned. The balloon in VM will be used to inflate and release
memory to hypervisor. The tube added for coiommu will be used by balloon
to send the unpin request during inflating.
BUG=b:188481989
TEST=Boot a VM
Change-Id: I2c75346b721ac639c803490f8850a1ee03e74194
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3292933
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Stevens <stevensd@chromium.org>
If crosvm register a req_irq eventfd on a vfio-pci device, kernel
vfio-pci driver will trigger this req_irq eventfd when the physical
device is removed from host.
So crosvm should register and monitor req_irq eventfd for vfio pci
device hotplug out, once req_irq eventfd is triggered by host
vfio-pci driver, crosvm should should inject an hotplug out interrupt
into guest, then guest device driver will be unloaded, finally host
vfio-pci driver will be unloaded and physical device is removed from
host.
BUG=b:185084350
TEST=Boot a guest and hotplug in/out pcie device repeatedly
Change-Id: Ia6e4c74b0ad5e87a4d2bea5631ef81e7120e07cb
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3062742
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
The unpin page framework will be used to handle the unpin request.
BUG=b:188481989
TEST=Boot a VM
Change-Id: I6d19a679c4626b8775d81e09ecca2a0fe6c58ec8
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3292931
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Stevens <stevensd@chromium.org>
Commit-Queue: David Stevens <stevensd@chromium.org>
Coiommu is a virtual PCI interface device. It provides pin page
functionality to the guest VM for the pass-through device through
the VFIO framework. With this, the guest VM doesn't need to pin pages
at the VM creating time but just need to do this through coiommu
frontend driver dynamically at runtime. Coiommu frontend driver will
send the pin request to the backend through device MMIO with the GFN
address. Backend then find out the proper HVA according to this GFN
and map this GFN to the HPA finally through the VFIO framework.
Unpin page functionality will be supported in the next patches.
BUG=b:188481989
TEST=Boot a VM
Change-Id: Iac347200305ed0cebe1456e3a0a353de83e6c80b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3292930
Reviewed-by: Chirantan Ekbote
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Stevens <stevensd@chromium.org>
Commit-Queue: David Stevens <stevensd@chromium.org>
Extend with read_only support so that the user can create a
read-only map for some read-only memory region, like read-only
memory backed MMIO bar.
BUG=None
TEST=Boot a VM
Change-Id: Ia6c1fd365808991f02298f7bbfaac0be8c801f8b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3292929
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Stevens <stevensd@chromium.org>
Commit-Queue: David Stevens <stevensd@chromium.org>
Use the PCI address function field to evenly distribute the chosen
interrupt line across the available pins.
This does not change behavior when all devices are allocated on a
separate device number (they will all have function 0 and therefore
choose interrupt pin A, as they do already).
BUG=b:210795995
TEST=boot crosvm with multi-function devices
Change-Id: I4b3e525ef784ac41b3f66cfddea192dd933d9907
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3343181
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Each device does not know whether it is a multi-function device when it
is created; this is only possible to determine once all devices have
been added to the PCI bus. Change the PCI root code to check for this
and update the multi-function bit dynamically at runtime.
The multifunction option for the stub PCI device is also removed; it
will be determined automatically, so there is no need for the user to
specify it.
BUG=b:210795995
TEST=boot crosvm with multi-function devices
Change-Id: Iff8306a41bb2bf23f97f45d29edc7791efc754bf
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3343180
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
GET_PARAMS and GET_PARAMS_EXT's reply can be delayed if a session is
ongoing but no input buffer has been received yet. When this happens we
store the command into a set of pending commands, but when doing so we
only allowed for a reply to GET_PARAMS to be returned, which causes the
wrong reply to be sent if the guest used GET_PARAMS_EXT. Fix this by
storing whether the EXT variant has been used as a boolean in the
command and replying accordingly.
BUG=b:193202566
TEST=arc.VideoEncodeAccel.h264_192p_i420_vm passes without https://crrev.com/c/3349429
TEST=arc.VideoEncodeAccel.h264_192p_i420_vm passes with https://crrev.com/c/3349429
Change-Id: I6d135c611a32d0f107ac9f437b046f4309b54dba
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3382501
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Knowing the decoding method used on the host can be useful to the guest,
e.g. in order to decide which format to use for buffers or to choose
between several acceleration options if more than one decoder or encoder
device exists.
Since this change only adds additional data to the device configuration
space, it does not introduce any incompatibility with existing guests.
BUG=b:161774071
BUG=b:169295147
TEST=Android Youtube plays properly on Hatch.
Change-Id: I2ba47504c17cefbceef16ccacc211856ef9fa30e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3026356
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
The features supported by a video device will depend on the backend in
use. For instance, the libvda backend only supports virtio objects for
memory buffers, whereas the ffmpeg backend will support both virtio
objects and guest pages.
BUG=b:209523781
TEST=Android Youtube can play videos on Hatch.
Change-Id: Ib55d959ae6a6d446d8ce0b75b411e50bc40204f9
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3143584
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
This change adds a command line parameter for instantiating a VVU proxy
device.
BUG=b:194136484
TEST=Test with sibling VM with Vhost master connecting to a device VM.
Change-Id: I5ff56e6f1ebca5a7078eca3d951ddbfd411d14fc
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3290381
Reviewed-by: Chirantan Ekbote
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Abhishek Bhardwaj <abhishekbh@chromium.org>
Having to create a Box for each backend failure is cumbersome. Add a
backend failure creation method that takes care of this for us.
BUG=b:161774071
TEST=Android Youtube can play videos on Hatch.
Change-Id: I3f290504820f855c30b17364c3cbc9997ad74b36
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3308317
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Add a method that allows to conveniently map resources into a linear
buffer, even if the resources are initially sparse (as is often the case
with user memory).
BUG=b:209523781
BUG=b:169295147
TEST=Android Youtube can play videos on Hatch.
Change-Id: If9a9b7764e6522da20d85e2ebca59a77b58573ac
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3308315
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Supporting guest memory is necessary for many guests that expect to
render into guest-allocated memory (as opposed to the virtio-object
method that is for now rather specific to Chrome OS). Add support for
this kind of memory in the form of SG lists.
BUG=b:209523781
TEST=Android Youtube plays properly on Hatch.
TEST=v4l2r's test decoder can allocate MMAP buffers.
Change-Id: I9864113ca2b88a23db8204ee7dd8d38801857c25
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2982247
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
The current code assumes that we will only ever have one entry per
memory resource, which is accurate for now, but doesn't allow us to
support memory pages resources (which can have several entries) or
multi-planar formats.
Fix this by reading the actually expected number of resources and
passing them to the device in a double-vector containing one set of
entries per memory plane.
BUG=b:209523781
TEST=arc.VideoDecodeAccelPerf.h264_1080p_30fps_vm passes on zork-arc-r with crrev.com/c/3358090 applied to the guest.
TEST=arc.VideoEncodeAccel.h264_192p_i420_vm passes on zork-arc-r with crrev.com/c/3358090 applied to the guest.
Change-Id: I984ee49c588c3a188e72bc04bc7f568f582523f5
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3379629
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
The current naming is a bit confusing: a resource is one or several
buffers that are each made of one or several entries. The elements that
we return to the device are thus resource entries (that need to be
resolved into a single resource) and not the whole resources themselves.
BUG=b:209523781
TEST=cargo build --features "video-decoder,video-encoder"
Change-Id: Ie3d89c48f9b3e7758b455ea1b2d4954daf248d0c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3379628
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
On the guest side application using V4L2 frontend can query frame
sizes using VIDIOC_ENUM_FRAMESIZES ioctl. This ioctl accepts pixel
format as an argument. It is correct to query frame sizes for input
format. In this scenario virtio-video would always return 0x0
resolution provided by crosvm, which is incorrect.
This patch fixes this issue by suppling correct frame sizes into
returned input formats.
BUG=b:160440787
TEST=tast run eve arc.Video*
Change-Id: Ib12b19ca515056aa8fa9470ece34309db2475817
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3377642
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Marcin Wojtas <mwojtas@google.com>
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>
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>
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>
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>
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>
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>
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>
