This script moves win_util from crosvm/common/ to crosvm/
and win_sys_util into base::windows.
The CL makes some prerequisite code changes needed to enable
building of tests after the script is applied.
BUG=b:223206469
TEST=presubmit
Change-Id: I5c1952596d3161730be3f42ce5d6cb554ab66b4a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3537257
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
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>
crrev.com/c/3523746 removed scoped_path from sys_util's public API.
Although nothing in crosvm uses scoped_path, it is used by cronista and
sirenia.
BUG=None
TEST=cargo build -p sirenia
Change-Id: Ia78363355049f5a4c03491f78ef169ebfecec164
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3539331
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: David Stevens <stevensd@chromium.org>
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>
This reverts commit 052f7df430.
Reason for revert: breaks tast.health.DiagnosticsRun.cpu_cache on volteer-manatee
Original change's description:
> x86_64: remove special-case mappings for direct
>
> Now that we can handle file-backed mappings that overlap with guest
> memory, we can remove the workarounds for coreboot regions when
> compiling with --features=direct.
>
> BUG=b:188011323
> TEST=cargo test -p x86_64 --features=direct
> TEST=Boot volteer-manatee and brya-manatee
>
> Change-Id: I9ac2a25e1896c5ec61bd302882d4c99d8b36b0dd
> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3498210
> Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
> Tested-by: kokoro <noreply+kokoro@google.com>
> Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
BUG=b:188011323
TEST=tast run health.DiagnosticsRun.cpu_cache
Change-Id: I313620d99726ed185ba2ec04df4413e43a612670
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3537260
Reviewed-by: Anton Romanov <romanton@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
This will allow us to merge sys_util and win_sys_util.
The original source locations will remain until they
are moved into the ChromeOS source base.
See go/future-of-sys-util for details
BUG=b:22320646
TEST=run it
Change-Id: Ie1adcadba9d35f18cc7472dc78f05262114a726f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3536890
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
sys_util will go away in the crosvm world, but base exports
the same symboles.
BUG=b:22320646
TEST=presubmit
Change-Id: Ibacba5821f7e9b734e58b21ffa376ee23db36d59
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3534503
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
The crate is only used by cros_async, which has already been
copied to crosvm.
The old source location will eventually move to ChromeOS.
See go/future-of-sys-util for details
BUG=b:22320646
TEST=presubmit
Change-Id: Icf3522497cb4e8c04a4687403466b781f0d7a9ee
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3534501
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Dennis Kempin <denniskempin@google.com>
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>
The copy is going to be used by crosvm going forward, while the
old version will eventually be moved to ChromeOS.
See go/future-of-sys-util for details
BUG=b:22320646
TEST=presubmit
Change-Id: Ic3216855fc244e366423160464dc722a04dfc56d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3533607
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>
Allows to specify which GPEs should be passed through as physical GPEs
for direct handling in the guest.
BUG=b:205072342
TEST=Run crosvm with "--direct-gpe 110" on Volteer or Brya with ACPI EC
driver disabled in hypervisor kernel. Observe if ChromeOS is receiving
events from EC:
- inspect /sys/firmware/acpi/interrupts/gpe6E on host and guest
- on EC console "ACPI query = 1" should appear immediately after
closing the lid
Change-Id: Iea6e3c4f2dcefa336b4fbf6d3485a309c789fb38
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3492224
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Tomasz Nowicki <tnowicki@google.com>
Wire up GPE eventfd forwarding and crosvm's GPE emulation.
This patch allows to provide ACPIPMResource with the list of GPEs
which should work as direct physical (passthrough) GPEs rather than
purely emulated ones.
BUG=b:205072342
TEST=see CL:3492224
Change-Id: Idb8ef36299c793f56d73246d15ff89f495bb30ef
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3492223
Reviewed-by: Dmitry Torokhov <dtor@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>
In order to listen on a specific netlink generic multicast group for a given
family (e.g. "acpi_mc_group" multicast group registered for "acpi_event" family),
we first need to get its group id registered by the kernel.
To achieve above, this commit implements two functionalities:
1) family name query (family_name_query), which prepares proper netlink
message, which is next send to netlink generic controller to query
kernel about a given family name. (e.g. it can be used to query about
"acpi_event" family)
2) parse the netlink generic answer and get group id registered for a
given generic netlink multicast group name (get_multicast_group_id)
(e.g. it can be used to get multicast group id for "acpi_mc_group").
BUG=b:197247746, b:205072342
TEST=Use introduced functionality to query about "acpi_event" generic
netlink family and get group id for "acpi_mc_group" group. Additionally
test the same after hacking the kernel and registering two other multicast
groups for acpi_event, so "acpi_mc_group" got a different group id. In
both cases successfully listen on "acpi_mc_group".
Change-Id: Ia7681fae2200ff5baebbad3742c9dd97ac59cae5
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3515924
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Tomasz Nowicki <tnowicki@google.com>
When pci_low_mmio allocates non-prefetchable bridge window for virtual
pcie root ports on brya-manatee, out of space error happens on one
virtual pcie root port.
Currently 756MB mmio is reaserved for pci low mmio and nearly 650MB could
be allocated, but byra has three pcie root ports, each pcie root port
reserve 194MB non-prefetchable bridge, so CrOS in brya-manatee needs at
least 194x3=582MB pci low mmio, consider bar alignment, 756MB isn't
enough for brya-manatee and the above error happen, so this commit
increate it to 1G.
BUG=b:185084350
TEST=boot brya-manatee and check bridge window allocation on each
virtual pcie root port.
Change-Id: I837f7dad459f624437ce6334719dfe337dea1d75
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3535683
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
The windows tests cannot be enabled because of dependency on base.
Some minor cosmetic changes.
Bug: b:213152499
Test: Build and presubmit
Change-Id: If11b9fa0784f1f37a5106e32b328306a4a2c0cf6
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3533582
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Vikram Auradkar <auradkar@google.com>
There is currently no use case for the PM timer in the guest and TMR_STS
is not implemented in vPM1, so disable it altogether for now.
BUG=b:199383670
TEST=boot manatee
Change-Id: I61b214a466becef2d923fdbfe450c31b08b70037
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3528533
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
In order to use netlink generic socket together with WaitContext,
AsRawDescriptor needs to be implemented.
BUG=b:197247746, b:205072342
TEST=Use NetlinkGenericSocket with WaitContext and successfully use it
for threads
Change-Id: I99c9d508c86395f104a7a2f17a1726b753c9698b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3528638
Reviewed-by: Daniel Verkamp <dverkamp@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>
Had to add some exceptions here because of some mismatches between
the structrure of files vs modules.
BUG=b:22320646
TEST=python tools/contrib/refactor_use_references
Change-Id: Ia9da533bd8c89871893adfa461e47e4e2fe600d9
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3530119
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
The max_read and max_write in worker::start_message_loop are confusing.
The max_read defines the amount of data the filesystem should be fed /
read from /def/fuse, during the write(2) operation to the filesystem.
The meaning is oppposite to the mount option max_read, which is for the
actual read operation.
This change adds API doc, fix the new API, and renames variables to
disambiguate them. With the new API, the meaning should be more
intuitive and consistent.
Bug: 220386264
Test: use in Android
Change-Id: Ifa77cb3c291626fdbb8a28f36cf2a44dd859f70f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3526527
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Victor Hsieh <victorhsieh@chromium.org>
An internal namespace is created as a signal to discourage the use of
the new public API directly.
BUG=b:220386264
TEST=Use the API. See multiple threads in the FUSE process
Cq-Depend: chromium:3514800
Change-Id: I8b9d6321c5dffedb27c6c1ddc6d6b0e125d3cf18
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3514618
Auto-Submit: Victor Hsieh <victorhsieh@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Victor Hsieh <victorhsieh@chromium.org>
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>
Do not warn if the `image_path` parameter is unused, as it is only used
if the composite-disk feature is enabled.
BUG=b:221887571
TEST=cargo build
Change-Id: I91f747152c0e5f4d75f7522a33d35f91890c6df6
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3531731
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>
Add a method to SystemAllocator that returns a vector of all pools and
use it to generate the PCI ranges in build_vm. This also fixes a bug
where x86 used the size as the end address for the high_mmio region.
BUG=b:181736020
TEST=tast run trogdor|hatch arc.Boot.vm
Change-Id: Id4a300ec61c15bc08fb069b80428b22461ca935b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3516668
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>
Use RangeInclusive when constructing an AddressAllocator. A followup
change will add an iterator constructor, so using RangeInclusive makes
that API cleaner.
BUG=b:181736020
TEST=cargo test
Change-Id: I59c28b9cbd06c86482c0c57704fc2753a7886ac6
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3516666
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>
Have the arch code return the SystemAllocatorConfig instead of a
SystemAllocator. This will be used to allow the core code to apply
additional restrictions on top of the arch code's restrictions.
BUG=b:181736020
TEST=compiles
Change-Id: I4d9ca277f039586e664648492c8744967dcd2ee5
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3516665
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: David Stevens <stevensd@chromium.org>
Windows vmm_vhost differs from linux vmm_vhost mostly on the structures
that it depends on. For example windows uses Tube for linux'
UnixStream.
The patch aliases some of these types in a platform specific file. Rest
of the platform independent code depends on those aliases.
Bug: b:213151429
Test: presubmit, manually run cargo test on windows.
Upstream-Crate: third_party/vmm_vhost
Change-Id: I3f98fbec1ffdd8914dc5befddce3a8483a5fd94f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3496082
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Vikram Auradkar <auradkar@google.com>
This is a prerequisite for sys_util* to move into the base
crate. The crate should never have been in common in the
first place since it is not shared.
BUG=b:223206469
TEST=python tools/contrib/cargo_refactor.py
Change-Id: I60115e0418c6980d7bf7ff624a3cc0a24e71a57d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3530502
Reviewed-by: Anton Romanov <romanton@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Vikram Auradkar <auradkar@google.com>
