Make the variable clearer by renaming it to represent the information it
holds i.e. the firmware file AND the fact that the VM is unprotected.
And to avoid confusing it with cfg.pvm_fw and components.pvm_fw, which
both actually hold the protected VM firmware (resp. path and image).
Note: no functional change intended.
BUG=b:243646855
TEST=build
Change-Id: Ieabc2f05798c3a0e969348d6dbd9a87ffb3a8ad0
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3867612
Commit-Queue: Pierre-Clément Tosi <ptosi@google.com>
Tested-by: Pierre-Clément Tosi <ptosi@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Return an Err when at least 2 protection flags are being used.
Previously, the error was only raised when all (3) flags were set.
BUG=none
TEST=build # then manually test the CLI
Fixes: 7910b89eb3 ("crosvm: move run command to argh")
Change-Id: I39588bf854fd659add68ac2e93a0ac6f26c8c813
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3867611
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Pierre-Clément Tosi <ptosi@google.com>
Tested-by: Pierre-Clément Tosi <ptosi@google.com>
On Windows, we don't use import_resource_to_display() + flip_to(),
but the newly added resource_flush(). This applies to both Vulkan
and D3D backend. We would need some refactoring for the GpuDisplay
interface to create a better abstraction.
BUG=b:213149288
TEST=presubmit
Change-Id: If1d3dc543a17aa7fabf591aa2c1b87b226e8a4a6
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3869171
Reviewed-by: Kaiyi Li <kaiyili@google.com>
Commit-Queue: Pujun Lun <lunpujun@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Pujun Lun <lunpujun@google.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
clippy can't tell that the non-default power-monitor-powerd branch does
need the match, so it complains that we can remove it. Add it to the
pile of allowed warnings.
BUG=b:243677117
TEST=tools/clippy # with Rust 1.62
Change-Id: Ic8ea873e49a063f52331b6f042251161d747e586
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3854972
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
The original syntax falls afoul of the new unit-valued let lint:
<https://rust-lang.github.io/rust-clippy/master/index.html#let_unit_value>
We can work around it by using the turbofish instead to specify the
type.
BUG=b:243677117
TEST=tools/clippy # with Rust 1.62
Change-Id: I1d7f774ed47850bcced4ee29118590a4462a52a7
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3854971
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
The functions being called do not have return values (they return the
unit value), so the `let _ =` does nothing and can be removed.
Fixes a new clippy lint:
<https://rust-lang.github.io/rust-clippy/master/index.html#let_unit_value>
BUG=b:243677117
TEST=tools/clippy # with Rust 1.62
Change-Id: I6003b162c36e7be1ee71e3edc4e304c86fdc5676
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3854970
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Remove the _bytes_read variable, since it is not needed. It was also
misnamed since we are writing, not reading, data.
Fixes a Rust 1.62 clippy lint:
error: this let-binding has unit value
BUG=b:243677117
TEST=tools/clippy # with Rust 1.62
Change-Id: I53f7b675f8e95c94ab127e500127a9153166a906
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3854968
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Bump the versions of these crates as we're about to require support for
unavailable register values and AArch64. Do it in a separate commit to
ease future bisects.
BUG=b:222222882
BUG=chromium:1141812
TEST=tools/dev_container ./tools/run_tests
Change-Id: I0bfa3559d172faf2df6bcffdc77714830f442051
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3785466
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Auto-Submit: Pierre-Clément Tosi <ptosi@google.com>
Tested-by: Pierre-Clément Tosi <ptosi@google.com>
Commit-Queue: Pierre-Clément Tosi <ptosi@google.com>
Reviewed-by: Takaya Saeki <takayas@chromium.org>
Make GdbStub query the number of available hardware breakpoints from the
VM as some architectures (e.g. AArch64) might permit a flexible number.
BUG=b:222222882
BUG=chromium:1141812
TEST=tools/dev_container ./tools/run_tests
Change-Id: I9220f642fc01939305bd17461eaf50c424d998bc
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3785465
Auto-Submit: Pierre-Clément Tosi <ptosi@google.com>
Commit-Queue: Pierre-Clément Tosi <ptosi@google.com>
Tested-by: Pierre-Clément Tosi <ptosi@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Takaya Saeki <takayas@chromium.org>
Remove target_arch-specific #[cfg]s where the underlying code is
architecture-agnostic.
Introduce a GdbOps trait for architectures to implement.
Make use of the generic gdbstub::arch::Arch trait where relevant.
Import base::Tube unconditionally in arch/src/sys/unix.rs.
Expand crate::gdb::* in vm_control/src/lib.rs for clarity.
Keep target_arch checks in x86-specific code to exclude 32-bit builds as
those don't seem to provide GDB support.
BUG=b:222222882
BUG=chromium:1141812
TEST=tools/dev_container ./tools/run_tests
Change-Id: I3f5ceeeb9031bee222ecd388dddb815e256748e8
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3785464
Tested-by: Pierre-Clément Tosi <ptosi@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Auto-Submit: Pierre-Clément Tosi <ptosi@google.com>
Commit-Queue: Pierre-Clément Tosi <ptosi@google.com>
We had the exactly same function `run_handler` in
/virtio/vhost/user/device/handler.rs and
/virtio/vhost/user/device/handler/sys/unix.rs. Since it's used only in
Unix-platform, remove the one in handler.rs.
BUG=none
TEST=build
Change-Id: I4378b201eef3eb6863d840d92e3933d35a9635e4
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3863045
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: Keiichi Watanabe <keiichiw@chromium.org>
Since specifying module with absolute paths (`crate::`) is preferred over
relative path (`super::`), replace all of them except `super::*` in
`tests` modules.
BUG=none
TEST=cargo test --all-features in vmm_vhost
Change-Id: I90d4906c02505395358c8722bcbb7d0bb3024733
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3863044
Tested-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Make tools/health-check cover third_party/vmm_vhost, as we are
maintaining vmm_vhost by ourselves and we don't pull the upstream
changes so frequently unlike other third_party components.
This CL includes:
* updates in scripts under /tools, and
* the auto-gerated changes by `./tools/fmt --nightly`
BUG=b:239937122
TEST=cargo check
Change-Id: I12956a60bb24764ffb541261c7fb3f09eb974dd8
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3863043
Tested-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Auto-Submit: Keiichi Watanabe <keiichiw@chromium.org>
Turn KvmVcpuRegister into an enum that supports any kvm_regs entry (not
just kvm_regs::regs i.e. user_pt_regs).
Improve the abstraction provided by KvmVcpuRegister through the 2-step
conversion "VcpuRegAArch64 -> KvmVcpuRegister -> u8", which allows more
flexibility when KVM doesn't provide 1-to-1 mappings (CCISDR, SVE, ...)
and when other types (e.g. gdbstub) need to be mapped to KVM_SET_ONE_REG
values.
Introduce the firmware pseudo-register type as a KvmVcpuRegister variant
and use it for KVM_ARM_PSCI_VERSION.
BUG=b:222222882
BUG=chromium:1141812
TEST=tools/dev_container ./tools/run_tests
Change-Id: Id11c427fc48f4b6bef9df607eeb73928aa7f5da7
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3785463
Reviewed-by: Takaya Saeki <takayas@chromium.org>
Auto-Submit: Pierre-Clément Tosi <ptosi@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: Pierre-Clément Tosi <ptosi@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
This change allows to turn off support for QCOW. This is useful for
projects that do not need/want it.
A follow-up change (if this one is merged) will do the same for Android
sparse disk images.
BUG=none
TEST=./tools/presubmit
Change-Id: I69083c4c2e21d504db89eff47f4c86c6f61d67e9
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3864926
Tested-by: Christian Blichmann <cblichmann@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Christian Blichmann <cblichmann@google.com>
This is useful for projects that build in lock-step with crosvm and want
to control a VM without having to `dlopen()` or embed
`libcrosvm_control.so`.
TEST=./tools/presubmit --quick
BUG=none
Change-Id: I9407c3e1783f55e399358bdf291a999ee8dc8892
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3864925
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Christian Blichmann <cblichmann@google.com>
Tested-by: Christian Blichmann <cblichmann@google.com>
Creating a context frequently involves optional parameters, and the
builder pattern handles this more descriptively, especially in the case
of an encoder context.
Encoder support is coming in a later commit, but it's a good idea to
align the decoder to use the builder pattern to ensure a consistent way
of doing things.
BUG=b:239897269
TEST=cargo test --features "video-decoder,ffmpeg" -p devices video
Change-Id: I92bd5f72b638c13a3257d54238b1beb229c64fa0
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3856042
Tested-by: Tatsuyuki Ishi <ishitatsuyuki@google.com>
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Tatsuyuki Ishi <ishitatsuyuki@google.com>
With more types going to support AvPacket in the future, it's probably
more maintainable to separate the construction of AvBuffer from the
consumer types.
The borrowing constructor will still take AvBufferSource generically as
it doesn't have a buffer object to construct.
As AvBuffer is directly used in the interface now, make its definition
and methods public.
BUG=None
TEST=cargo test --features "video-decoder,ffmpeg" -p ffmpeg -p video
Change-Id: I0959d383438a94d562fc6ff34c40389e98be7bfd
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3833772
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
Commit-Queue: Tatsuyuki Ishi <ishitatsuyuki@google.com>
Tested-by: Tatsuyuki Ishi <ishitatsuyuki@google.com>
The fs device option was parsed but did not get copied into Config, so
we never attempted to create any vhost user fs devices.
BUG=b:244454265
TEST=crosvm run --vhost-user-fs ...
Change-Id: Ia3ed49681a5da2190325f9b59e4a61884509cb20
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3867534
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
The existing flags assume unix libc read = 1, write = 2. On Windows we
have read = 4, write = 2. We can implement the conversion between
base::Protection and VhostUserShmemMapMsgFlags to keep the protocol
itself separate from the platform flags.
BUG=b:221882601
TEST=presubmit & tested downstream
Change-Id: I6fe69df679926b240f7d02dfbbf0704bbca5a5b0
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3860646
Reviewed-by: David Stevens <stevensd@chromium.org>
Commit-Queue: Idan Raiter <idanr@google.com>
Tested-by: Idan Raiter <idanr@google.com>
The exact internals of the API may change though. For example,
using a device UUID is a less error-prone than using physical
device index.
However, this is sufficient to get gfxstream external memory on
atleast some platforms.
BUG=b:235485545
TEST=compile and run ./deqp-vk with kFeature_ExternalBlob enabled
Change-Id: I10d2aaecfbcd61f383dd326184e60942755db196
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3864029
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Idan Raiter <idanr@google.com>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
As a stepping stone toward fully asynchronous disk formats, add a
wrapper that takes a regular synchronous DiskFile and provides the
async disk API.
BUG=b:219595052
TEST=cargo build --features=composite-disk
Change-Id: Id785ad7ff69ae869a8a9007134fdb4fe7f3be4ba
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3824066
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Noah Gold <nkgold@google.com>
The previous signature allowed lifetime laundering if code like below
was used:
impl<'a> AvBufferSource for &'a mut [u8] { ... }
fn foo() {
let mut storage = vec![];
let buf = AvBuffer::new(storage.deref_mut());
drop(storage);
// buf can be used after free
}
Add a 'static bound to prevent it.
BUG=None
TEST=cargo build --release --features "video-decoder,ffmpeg" -p devices
Change-Id: Ifda2793a3e3d4d8b400fa076f1d6f9474d0ae159
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3833771
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Tatsuyuki Ishi <ishitatsuyuki@google.com>
Tested-by: Tatsuyuki Ishi <ishitatsuyuki@google.com>
The `buf_lens` vector was created only to be destroyed in the next line.
Just use `sum()` on the buf iterator.
BUG=None
TEST=tools/presubmit --all
Change-Id: Iddfa4f783b6eda326b9dbb9c6a1f443b7976ca2c
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3858688
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Auto-Submit: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Values 0 and 1 can be represented with one-byte binaries.
BUG=None
TEST=./tools/presubmit
Change-Id: If5d61c598087118858a6b57799ab1b90ad729f70
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3859217
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Auto-Submit: Victor Ding <victording@chromium.org>
Tested-by: Victor Ding <victording@chromium.org>
Currently both direct and non-direct GPEs are unconditionally forwarded
to the guest, just in different ways. This is wrong not only because we
don't necessarily want to propagate the given non-direct GPE to the
guest, but also because non-direct GPEs are forwarded without preventing
handling them in the host, so that a GPE handler is run twice: in the
host and in the guest. This behavior doesn't seem to make sense and is
generally buggy.
The idea of this patch is that acpi device code should forward direct
GPEs only, and for non-direct GPEs it should just notify the registered
gpe_notify listeners, if any. Those listeners may then inject the given
GPE to the guest or do something else, depending on the purpose of the
given GPE.
This patch doesn't change any behavior for direct GPEs, so currently it
doesn't affect ManaTEE, since currently all 4 GPEs on Brya/Volteer are
used as direct GPEs. However in the future we may use non-direct GPEs
e.g. for a cleaner solution for handling Thunderbolt hotplug GPE.
BUG=b:230592368
TEST=Inspect /sys/firmware/acpi/interrupts/ to see if GPE events (EC,
Thunderbolt etc) work correctly in ManaTEE. No specific test for
non-direct GPEs, since we don't use them.
Change-Id: I4c9b59c217ce347cfe06decf25694cbf6c4170f4
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3861973
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Dmytro Maluka <dmaluka@google.com>
Tested-by: Dmytro Maluka <dmaluka@google.com>
It is wrong to unconditionally propagate ACPI power button events in the
host to the guest, since some guests (e.g. ARCVM) don't expect them and
misbehave when such an event is received. If at all, this propagation
should be enabled only in crosvm builds with "direct" feature enabled,
i.e. crosvm-direct builds for ManaTEE.
Moreover, even for ManaTEE, the correct approach is to propagate them
via direct forwarding of physical ACPI events, rather than via listening
on ACPI netlink events in the host (in particular because we want them
to be handled in the guest only, not in the host).
Since CL:3645408 and CL:3599200 we are using direct forwarding of ACPI
power button events, so the netlink based forwarding in the ACPI event
listener is no more used by anyone and can be removed.
BUG=b:241191471, b:230592368
TEST=ACPI power button events are not propagated to ARCVM guest.
Change-Id: I2541bf900d51507dc246b46fb6691dfa0b1c2956
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3859626
Tested-by: Dmytro Maluka <dmaluka@google.com>
Reviewed-by: Grzegorz Jaszczyk <jaz@semihalf.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Dmytro Maluka <dmaluka@google.com>
It's not a problem if some ACPI events generated in the host are
ignored by crosvm ACPI event listener.
BUG=None
TEST=No "unknown acpi event battery" warnings in ARCVM and Crostini
Change-Id: I4961b4637fa79cbebc0b2e2afc86ad8da598f8fd
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3859625
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Dmytro Maluka <dmaluka@google.com>
Reviewed-by: Grzegorz Jaszczyk <jaz@semihalf.com>
Commit-Queue: Dmytro Maluka <dmaluka@google.com>
This reverts commit 5cdeb2a8b3.
Reason for revert: broke xTS decoder tests b/244113170
Original change's description:
> virtio: video: decoder: reset session when input queue is cleared
>
> Clearing the input queue means a reset of all parameters, so reset the
> session when it happens. This allows the guest to change input
> parameters after a reset.
>
> BUG=b:161774071
> TEST=ffmpeg in the guest does not complain that "parameter for input cannot be changed once decoding started" upon exit.
> TEST=tast arc.VideoDecodeAccel*_vm passes on hatch.
>
> Change-Id: I2e25ddc01d99cb9ce39f0dbf9bbb9413084dba19
> Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3841482
> Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
> Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
> Tested-by: Alexandre Courbot <acourbot@chromium.org>
BUG=b:161774071
BUG=b:244113170
TEST=CtsMediaTestCases android.media.cts.DecoderTest#testCodecResetsH264WithSurface
Change-Id: I532e72c6abb49677fd20e755c7369a361e821bdb
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3859215
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Behavior should be exactly the same.
- Use `CpuSet::new()` directly instead of duplicating its code
- Use the `syscall!()` macro for error handling
TEST=./tools/presubmit
BUG=None
Change-Id: I371e9a113914db7ffdecbf4bf8770be157368569
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3858174
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Auto-Submit: Christian Blichmann <cblichmann@google.com>
Reviewed-by: Christian Blichmann <cblichmann@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: Keiichi Watanabe <keiichiw@chromium.org>
Support parsing negative numbers with a specified radix as e.g.
`-0xff00` instead of `0x-ff00`. This is a potentially breaking change
but I don't believe anyone made use of the former syntax anyway.
The new number parser has the nice side-effect of removing some extra
code, and also signaling parsing errors more accurately, so that's an
added bonus. On the other hand we lose the distinction between "invalid
number" and "expected number", but that distinction was dubious anyway
so losing it is for the better IMHO.
BUG=b:218223240
TEST=cargo test -p serde_keyvalue
Change-Id: I6b2943ecd0df92071afe0682b339dcf5b59e2826
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3853315
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Tatsuyuki Ishi <ishitatsuyuki@google.com>
Virtio MMIO device needs only one MMIO region and one edge-triggered
IRQ. Both based MMIO address and IRQ number are allocated dynamically.
BUG=b:189182339
TEST=boot manatee and verify that Virtio PCI devices work properly
Change-Id: Icdd6213068ef05c5a71e23728e2a4e1d69ac454b
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3855009
Commit-Queue: Tomasz Nowicki <tnowicki@google.com>
Tested-by: Tomasz Nowicki <tnowicki@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Lookup Vitio MMIO devices and allocate resources:
- hardcoded 0x200 size single MMIO region to configure vrings
- just one shared and edge-triggered IRQ to notify guest
- per-queue ioevents to poke host
Then plug device into main bus.
BUG=b:189182339
TEST=boot manatee and verify that Virtio PCI devices work properly
Change-Id: Ic255b2c9cdf1cb43b8663d39970daf54e55c6eed
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3855008
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Tomasz Nowicki <tnowicki@google.com>
Commit-Queue: Tomasz Nowicki <tnowicki@google.com>
As an alternative to PCI transport, instantiate Virtio MMIO device.
The caller which create Virtio device (and corresponding VirtioDeviceStub)
needs to mark device as MMIO type explicitly, otherwise PCI transport is
the default choice.
BUG=b:189182339
TEST=boot manatee and verify that Virtio PCI devices work properly
Change-Id: Id28345f5b004ebd0d8cfeb9ecd2966c3b821a4ea
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3855007
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Tomasz Nowicki <tnowicki@google.com>
Commit-Queue: Tomasz Nowicki <tnowicki@google.com>
