This will be run on crates that are to be moved into the
base crate.
The script is run in the follow up CL.
Note: This is a one-off script. It just has to work one,
not for the general case.
BUG=b:223206469
TEST=python tools/contrib/refactor_use_references.py
Change-Id: Ic92109572649c9130784b986c67fddc8f9b838d6
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3530497
Reviewed-by: Anton Romanov <romanton@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This allows us to move the composite disks and partitions around instead
of needing to know the paths beforehand.
BUG=b:221887571
TEST=Manual test with composite disk created via mk_payload.
Change-Id: Ifab86bc62509e58cc95b0f8420bffc554d60f380
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3499408
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Richard Fung <richardfung@google.com>
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>
Update links still pointing to master, update to point to HEAD
BUG=b:224796805
TEST=navigate to updated link and/or N/A
Change-Id: I1777c32e4e455cfeb95cf82c944d1adbca350767
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3525743
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
ScopedEvent's implementation was the exact same in 3 different places.
Bug: b:215618500
Bug: b:223840386
Test: ran emulator
Change-Id: I835ef9c523936dd651652f344f4857515afb8bdd
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3523746
Reviewed-by: Richard Zhang <rizhang@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Vikram Auradkar <auradkar@google.com>
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>
This is as is upstream of win_sys_util except following changes
1. Ignores flaky tests in syslog.rs and priority.rs - a todo is added.
2. Ignore this crate of unix tests/clippy.
3. Fix few doctest issues on windows.
The files are pulled from downstream repo at
Commit-Id: 53e8dfa6ec26de3f2ea2b637a5bfef96703214f3
Downstream-Change-Id: I5dd9e70566330b469fe245fc71451fb4dcd7e1ba
The cl should not affect unix binaries.
Bug: b:223840386
Test: Tested on windows by running
1. cargo test --all-features
2. cargo clippy
3. cargo fmt
Change-Id: I454f2e03b6269f374d107b83c8223ce98b9e29bf
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3514125
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Vikram Auradkar <auradkar@google.com>
Since this is a windows specific crate, we will skip building and
testing the crate on unix.
The files are pulled from downstream repo at
Commit-Id: 53e8dfa6ec26de3f2ea2b637a5bfef96703214f3
Downstream-Change-Id: I5dd9e70566330b469fe245fc71451fb4dcd7e1ba
The cl should not affect unix binaries.
Bug: b:213149154
Test: cargo test on windows
Change-Id: I1be598c119891a6c45b4f397463bcb0a8d89b65c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3515653
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Vikram Auradkar <auradkar@google.com>
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>
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>
In general irqchip finalizes setup and finalize_devices() should be called
once all devices have registered irq events and been added to the io_bus
and mmio_bus.
Split irqchip finilize_device() implementation in particular,
hands over requested irq events to IOAPIC in order to emulate pin state
and do proper forwarding when needed.
Move direct-irq registration before irqchip finalizes so that direct-irq
is taken into account. Note that direct-irq does work with kernel irqchip
implementation because its finalize_devices() is empty.
BUG=b:184871003
TEST=boot guest using crosvm --split-irqchip flag and check if IOAPIC
related IRQs are working
Change-Id: I78dbace08eee4a5bc91695fd8b8d41a84e58cde9
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3494284
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Steven Richman <srichman@google.com>
Commit-Queue: Tomasz Nowicki <tnowicki@google.com>
fuse::worker::start_message_loop is not a scalable API, so deprecate it.
This paves the way to support multiple threads.
BUG=b:220386264
TEST=Modify a client in Android to use the API
Change-Id: I41e8d5267384311a7b03beb67f7774332863fbf7
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3514617
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Victor Hsieh <victorhsieh@chromium.org>
Always advertise support for ACPI reset register, regardless of FADT
forwarding. The current reset register points to the PCI reset register
(CF9), which is always virtualized.
The Linux x86 kernel prioritizes using the ACPI reset register in its
reboot flow.
BUG=b:199383670
TEST=boot Linux kernel and reboot
Change-Id: Ib644e1062eb6e040d16c0c8d7cec2a54a86b3918
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3350495
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Tomasz Nowicki <tnowicki@google.com>
Support injecting GPE using "gpe x" in the command line.
BUG=b:199383670
TEST=boot Linux kernel and inject GPE via command line
Change-Id: I512a1f3973c5da2ef06b17d5ac7c7981261f2514
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3350494
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@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>
Support injecting an ACPI fixed power button event using "powerbtn" in
the command line.
BUG=b:199383670
TEST=boot Linux kernel and trigger a power button event
Change-Id: I5ed57f533fa3d91043491fd1f0695223a139fc7a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3350492
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>
Previously, when FADT is forwarded to the guest, "direct-pmio" is
usually used to give the guest full access to the physical PM1
registers.
Switch to using vPM1 registers always and overwrite the relevant FADT
fields.
Per spec, the I/O port addresses of PM1A_EVENT_BLK and PM1A_CONTROL_BLK
only need to be 32-bit aligned.
BUG=b:199383670
TEST=boot Linux kernel and shut down
Change-Id: Id29df44000d6654615afefd0be6662e4fe96c86e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3350490
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>
Rather than manually adding special handling for regions where we want
to put --file-backed-mapping mappings, we can just iterate over those
regions before constructing the GuestMemory object so that there will be
no conflicts/overlaps between RAM and file-backed mappings.
BUG=b:188011323
TEST=Boot volteer-manatee and brya-manatee
Change-Id: I986f33460fa45cd1f85d849810e1f6934cc73c0d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3489809
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Mattias Nissler <mnissler@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Now that the address allocator returns different error types for overlap
(Error::ExistingAlloc) and allocation attempts outside the managed
region (Error::OutOfSpace), we can disallow file mappings that overlap
MMIO regions while still allowing mappings elsewhere (e.g. in the normal
guest RAM regions). The next commit will modify the GuestMemory setup so
that file mappings that overlap guest RAM will be handled correctly.
BUG=b:188011323
TEST=tools/presubmit
Change-Id: I0e9ad8d97d0cb2f0a2a8d74516582eefd230fe8f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3498209
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
Reviewed-by: Mattias Nissler <mnissler@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
If AddressAllocator::allocate_at() fails, check if there is an existing
overlapping allocation and return it with Error::ExistingAlloc if so;
otherwise, return Error::OutOfSpace as before. This allows the caller to
distinguish between failure due to overlap and failure due to a range
that is not managed by the allocator at all.
BUG=b:188011323
TEST=cargo test -p resources
Change-Id: I1f6cde63a995dc461db221c509f4d0a1f0c7f186
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3498208
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
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>
The second block of OsStr and PciAddress parsing into host_addr was an
exact duplicate of code earlier in the function. Reuse the existing
host_addr variable instead of parsing it again.
BUG=None
TEST=tools/presubmit
Change-Id: I1cd65701a07636daa6e537d97abff808397d3181
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3488160
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
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>
cargo fmt will only format those files that are referenced by
crosvm. To really catch all files in our source tree, we need to
run rustfmt directly.
This will check files multiple times, since rustfmt will follow
included modules. But is still faster that cargo fmt.
To run these in parallel, this change adds some tools to common.py
for parallel execution of commands.
This reduces the fmt check time from ~9s to 1.5s.
I verified that we are actually catching all files now by adding a
newline to all .rs files in our sources tree. The formatter reverted
them all.
BUG=b:218559722
TEST=./tools/fmt
Change-Id: If721d837ebc9eee3ce28fa7f439ab0bcc0b993cf
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3474926
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
The original io_uring bindings were hand edited to eliminate some of the
anonymous unions, so there are some changes in the helper functions.
BUG=b:218388029
TEST=tools/presubmit --quick
Change-Id: I8e049296020dd38ba7c97b096ca6cc346b0a20d7
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3339805
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
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>
Add an option to allow creating a virtio-iommu device backend without
attached vfio device. This is for hot-pluggable devices whose DMAs are
restricted by the virtio-iommu backend.
BUG=b:185084350
TEST=Boot a guest with crosvm option "--virtio-iommu", a virtio-iommu
device can be seen in guest
Change-Id: I7799cb6ae3051f8ce2b6069a856480a9c9485fef
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3301702
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
