Device want to get notification when a specific gpe happens, this commit
add register_gpe_notify_dev(gpe_num, dev) interface into PmResource trait,
so that others could register (gpe_num, dev) into acpi, then they
could get notification at specific gpe trigger.
BUG=b:185084350
TEST=Verify TBT pcie hotplug function in ManaTEE, virtual pcie root port
must get gpe notification during this process
Change-Id: I56eb90361a6b96be364d35c4b6a5ec598a50757e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3539566
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Currently, VfioPciDevice always use the same BDF as the device's BDF in
the host OS. However, in certain applications (e.g. Borealis), it is
desired to map the device to a different BDF.
This patch introduces a new parameter to `vfio` so that user could set
the device's BDF to a desired address.
BUG=b:208545409
TEST=Boot Borealis with `--vfio=/path/to/dGPU,guest-address=00:11.0` and
confirmed that the dGPU is at 00:11.0 in the guest OS.
Change-Id: I7ee9e9a7f74e3541e74f89d452f9aad45302eeb4
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3535461
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Auto-Submit: Victor Ding <victording@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Victor Ding <victording@chromium.org>
The vhost-user VMM process is supposed to stop before the device
process, and the device process is supposed to get
`vmm_vhost::Error::ClientExit` when the VMM stops. Add the check in the
existing unit test.
BUG=b:219674197
BUG=b:220639724
TEST=cargo test in /devices/
Change-Id: I1768b9b43855e3b80f1e6e175877317338309e8a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3543005
Reviewed-by: Vikram Auradkar <auradkar@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Add dedicated tracking for mmio bar mmaps. This allows us to remove the
special case handing that ignores writes of 0 and 0xffffffff to the bar
configuration registers. That handling was actually broken because it
used || instead of &&, which resulted in bars being redundantly
remapped.
BUG=none
TEST=Add logs to set_user_memory_region, boot manatee, and check that
the same regions are mapped.
Change-Id: Ic9905330874a4c05f79dbdaee3b40b4d21a488ff
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3535468
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: David Stevens <stevensd@chromium.org>
Use our new serde_keyvalue crate to annotate the DiskOption structure
and allow us to deserialize it from a key-values string. Add tests to
help ensure parsing won't break in the future.
The existing `root`, `rwroot`, `disk` and `rwdisk` arguments can be
parsed in a compatible manner. In the future it would probably make
sense to merge them all into a single `disk` option since all variants
can now be specified as key-values.
BUG=b:218223240
TEST=crosvm run ... --rwroot /path/to/disk.raw
TEST=cargo test -p devices virtio::block::block::tests::params_from_key_values
Change-Id: I2c8b853b9817aefce0c5f0f5c4d5a1da1f9a45d9
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3473708
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>
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>
