Also adds settings to .vscode/settings.json to use the correct
formatter and type checking settings out of the box.
VSCode uses pyright and health-check uses mypy. They do not always
agree unfortunately, mypy is a little more lenient.
Unfortunately pyright is hard to get working with our scripts that
have no file extension.
BUG=b:242605601
TEST=./tools/health-check
Change-Id: Iaef4ac6f61613e7dda409d5e717102ea9adefe82
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3833699
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Tested-by: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Repeat the help text present in the run command. The duplication is
unfortunate but there doesn't seem to be a better way to handle this
with argh at the moment.
BUG=b:217480043
TEST=cargo build
Change-Id: I36bc2ff030f161f4c4ea3572fb31525cc8435cfd
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3827607
Tested-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
Make sure the serial parameters are properly validated when given to the
"devices" command as they are with the "run" command.
BUG=b:217480043
TEST=cargo build
Change-Id: Id582165819d1f3dc830cf1cf6c8b74cd688a76e2
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3827606
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Add proper handling for VIRTIO_F_ACCESS_PLATFORM with vhost devices. In
particular, the virtio flag can't be passed directly to vhost. If the
flag is set because of viommu translation, then the vhost IOTLB APIs
need to be used to propagate that information to the vhost driver. Since
crosvm doesn't implement this, fail in that case. If the flag is set for
other reasons (e.g. the guest bounces DMA through a DMA region, but
still uses raw GPAs), then don't enable IOTLB translation within vhost.
This is part of a deeper problem where crosvm assumes that virtio flags
are equivalent to vhost flags. While this is usually true, crosvm cannot
assume that arbitrary feature flags can be handled automatically by
vhost. Crosvm really needs to have allowlist based flag handling.
BUG=b:241034776
TEST=atest MicrodroidTestApp
Change-Id: Ifa1cd432889ff64be836371e40f37b89cab3b640
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3827609
Tested-by: Andrew Scull <ascull@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: David Stevens <stevensd@chromium.org>
Reviewed-by: Andrew Scull <ascull@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
SndParameter deserialization has been changed to use serde. The current
test for cras related parameter is using parse from string. It causes
compile error because some FromStr method has been removed. It needs
to be changed to use serde_keyvalue::from_key_value
BUG=b:242131810
TEST=add chromeos as a feature in src_test crosvm-9999.ebuild
TEST=FEATURE=test emerge crosvm
Change-Id: I5552b0f141debacaa30a93754f510bbf8ac621b5
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3827109
Reviewed-by: Chih-Yang Hsia <paulhsia@chromium.org>
Tested-by: Norman Bintang <normanbt@chromium.org>
Commit-Queue: Norman Bintang <normanbt@chromium.org>
`cargo test -p cros_async --doc` is failing with FdExecutor since the
example tries to seek a pipe. With UringExecutor, this error doesn't
happen by chance due to the difference in the implementation detail. So,
you need kernels prior to 5.10 to reproduce this issue.
This commit fixes the failure by not seeking a pipe.
BUG=b:242515595
FIXED=b:242515595
TEST=cargo test -p cros_async --doc succeeds.
Change-Id: Ifa97eb85d3b72061f1754e22108017df327c85d9
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3831841
Tested-by: Takaya Saeki <takayas@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Takaya Saeki <takayas@chromium.org>
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
QEMU's probe of the pflash device[1] expects to be able to clear the status
register, perform a read of the same location, and then read the status
register with the cleared state. To accomplish this only set the READY
status on an explicit READ_ARRAY command.
[1]: https://github.com/tianocore/edk2/blob/master/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.c
BUG=b:238344840
TEST=Added test for specific case
Change-Id: I81b326d4a546bb03fb55b766b630153ffbc758c5
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3831261
Tested-by: Mike Gerow <gerow@google.com>
Auto-Submit: Mike Gerow <gerow@google.com>
Commit-Queue: Mike Gerow <gerow@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
This CL migrates Tube from directly using a UnixSeqpacket to instead use
a StreamChannel backed by UnixSeqpackets. This CL also migrates users of
the old Tube::new(UnixSeqpacket) function to its renamed counterpart.
Tests are added for new functionality.
This CL enforces that the StreamChannel used by the Tube is backed by a
UnixSeqpacket because the reading and writing behavior of a UnixStream
is different, and it cannot guarantee the same multi-process
concurrent-writers behavior that a UnixSeqpacket can. This is because
the UnixStream does not send data as packets and the size cannot be
queried, so two underlyig writes are required for each Tube write: one
to send a header indicating message size, and one for the actual content
of the sent data. These can be interleaved during concurrent writes,
causing corruption of the Tube's data.
This CL makes the Windows and Unix API closer to each other, with some
differences remaining or added, including Tube::new_from_unix_seqpacket
existing in Unix but necessarily not Windows.
This migration (Tube from UnixSeqpacket to Stream) is intended to move
the Unix Tube API closer to the Windows API, with the eventual goal of
creating a platform-agnostic API for Tube.
Bug: b:231641496
Change-Id: I2422e76b7efa5a20bc40a8d194f5f8390dc71438
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3818253
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Noah Gold <nkgold@google.com>
Tested-by: Clarissa Garvey <clarissagarvey@chromium.org>
Commit-Queue: Clarissa Garvey <clarissagarvey@chromium.org>
This CL is one of two CLs in a series that migrate the Unix Tube from
using UnixSeqpackets directly to instead use StreamChannels backed by
UnixSeqpackets. This CL adds some pass-through functions to
StreamChannel that are needed by Tube in the follow-up CL, as well as
a new function to create a StreamChannel directly from a UnixSeqpacket.
Additionally, a test is added for the new constructor-like function.
This migration (Tube from UnixSeqpacket to Stream) is intended to move
the Unix Tube API closer to the Windows API, with the eventual goal of
creating a platform-agnostic API for Tube.
Bug: b:231641496
Change-Id: I8d7da6a0e64d38d8f9833ae8e62ec7a2c4cfda5c
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3818249
Tested-by: Clarissa Garvey <clarissagarvey@chromium.org>
Reviewed-by: Noah Gold <nkgold@google.com>
Fixes:
error[E0433]: failed to resolve: use of undeclared type `GpuMode`
--> src/crosvm/sys/unix/config.rs:191:62
|
191 | if gpu_params.vulkan.is_none() && gpu_params.mode == GpuMode::ModeGfxstream {
| ^^^^^^^ use of undeclared type `GpuMode`
error[E0433]: failed to resolve: use of undeclared type `GpuMode`
--> src/crosvm/sys/unix/config.rs:197:17
|
197 | GpuMode::ModeGfxstream => {}
| ^^^^^^^ use of undeclared type `GpuMode`
error[E0609]: no field `vulkan` on type `GpuParameters`
--> src/crosvm/sys/unix/config.rs:191:23
|
191 | if gpu_params.vulkan.is_none() && gpu_params.mode == GpuMode::ModeGfxstream {
| ^^^^^^ unknown field
BUG=b:239639751
TEST=cargo build --features=gfxstream
Change-Id: I1840ab0a5aca792595fcb3cbbc7406f80740873c
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3832397
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Auto-Submit: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
0x402 is the port OVMF expects to use, and is the most likely we'll end
up using.
TEST=deployed to hatch device, ensured default port allowed OVMF to
print debug logs
BUG=b:239706232
Change-Id: I607a3a042e3f066a3372c0307b1f5bbf6c20258d
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3829848
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Mike Gerow <gerow@google.com>
Auto-Submit: Mike Gerow <gerow@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Since luci recipes are updated asynchronously, we had to keep
the old check names around. Now that all builders are updated,
we can remove it.
BUG=b:239255137
TEST=CQ
Change-Id: I0550912d466045e12da1717cdb96346de9474ab7
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3831283
Tested-by: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
The check will verify that the Cargo.lock file is current. This
catches issues where conflicting changes would leave ToT with
an outdated lockfile.
BUG=b:240435583
TEST=./tools/health-check lockfiles
Change-Id: Idd92fe58d3b76f62582848673cbfdd18698ac3e8
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3811202
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Tested-by: Dennis Kempin <denniskempin@google.com>
We originally removed it because we had frequent merge conflicts
and all downstream projects were doing their own pinning already.
We also had CI issues because ChromeOS changes could trigger
Cargo.lock changes in crosvm back then.
The new Cargo.lock format should ease the merge conflicts and we
no longer have issues with external changes triggering changes
in our Cargo.lock. So let's bring it back in.
This will allow us to judge the impact of changing third party
dependencies and gives us a chance to implement a special
review process.
BUG=b:240435583
TEST=CQ
Change-Id: Ie53e5616cc98d7e50a84f3c0a91902dd539f2520
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3795655
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Noah Gold <nkgold@google.com>
Reviewed-by: Vikram Auradkar <auradkar@google.com>
Tested-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
The auto-generated _OSC in DSDT is incorrect, fixing it.
BUG=None
TEST=Dump DSDT table and verify the generated _OSC
Change-Id: Ib6c5c355a7b6ebb6c891b8f3c685e59d4117abad
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3831821
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Auto-Submit: Victor Ding <victording@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
The updated health-check will by default only run on modified
files. If you do not make changes to python code, python checks
won't run, etc.
The script also simplifies the writing of those checks so we can
start adding more of them.
Luci will be updated to make use of the --list-checks function to
run each check in a separate luci step. In the meantime, we
keep a compatibility layer to translate the old arguments
to the new style.
BUG=b:239255137
TEST=./tools/health-check in all it's variations
Change-Id: I21b986b46c7cfccf3d13f4c76bbd3d0ec7240c26
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3827174
Tested-by: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Allow vhost-user block to use multiple virtqueues (max: 16).
Note that not all of 16 vqs that crosvm prepared will always be used by the
guest. In the current Linux implementation, the number of vqs are
bounded to min(16, |# of sibling VM's vcpus|) because of a kernel
commit:
"bf348f9: virtio-blk: limit number of hw queues by nr_cpu_ids".
BUG=b:181753022
TEST=Run vhost-user block with 2 vcpus and checked the numbers of vqs
TEST=Run vvu block device with 2 vcpus and checked the numbers of vqs
Change-Id: Ibdb091261abea924ebcbcec98ce54bb3fac2f4bb
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3826604
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Noah Gold <nkgold@google.com>
Tested-by: Keiichi Watanabe <keiichiw@chromium.org>
Extract the part of building the virtio video config and the backend
device to standalone functions so that other modules such as vhost-user
video backend can use them.
BUG=None
TEST=simple_decoder test script (see the crosvm book)
worked with both the virtio video and the vhost-user video, but with
URingExecutor disabled (b/238965061).
Change-Id: Iaf6926e81fa67f0048058f1178106b5cc0a5a7bf
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3800843
Commit-Queue: Takaya Saeki <takayas@chromium.org>
Tested-by: Takaya Saeki <takayas@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Change current manual Virtio Snd Parameters deserialization to use serde.
BUG=b:242131810
TEST=emerge crosvm
TEST=tast run vm.AudioAplay
Change-Id: I00a9eab78f23ede98f69c12fb9ac4316d2dba3ad
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3823192
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Chih-Yang Hsia <paulhsia@chromium.org>
Tested-by: Norman Bintang <normanbt@chromium.org>
Commit-Queue: Norman Bintang <normanbt@chromium.org>
Add tracking to VmMemoryRequest.execute so that only requests which were
mapped with VfioDmabufMap get unmapped with VfioDmabufUnmap. This fixes
a deadlock that occurs when unregistering memory before the viommu
device is started, which is triggered by VfioPciDevice on ManaTEE.
Note that although a deadlock with registering memory is still possible,
this doesn't seem to be a problem in practice. Registration of such
buffers is driven by the virtio-gpu driver, and thus tends to occur
later during guest boot.
BUG=b:235508487
TEST=boot brya-manatee
Change-Id: I080d27b43d01a01b7d962b62c986d837be72b288
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3830133
Tested-by: David Stevens <stevensd@chromium.org>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Auto-Submit: David Stevens <stevensd@chromium.org>
Commit-Queue: David Stevens <stevensd@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Write profiles to a temp file and download them afterwards.
BUG=b:239255082
TEST=./tools/run_tests --target=vm:aarch64 --generate-lcov=aarch64.lcov
Change-Id: I1c81dd72aadca4cad3310347d94596d45a0e0ede
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3821463
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Tested-by: Dennis Kempin <denniskempin@google.com>
Coverage has been integrated into build_linux.
BUG=b:239255082
TEST=None
Change-Id: I3b6229c2b44b73bb24748e667fd1b334dcfe418c
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3820349
Tested-by: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
DevicesSubcommand was for the `device` command, so rename it to avoid
confusion with the `devices` one.
BUG=b:217480043
TEST=cargo build
Change-Id: I4c321ff61a71d0ca731b23951d583beb9ce5d46c
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3827603
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Alexandre Courbot <acourbot@chromium.org>
Auto-Submit: Alexandre Courbot <acourbot@chromium.org>
This is actually highly unsound since it allows you to write arbitrary
garbage to the buffer pointer fields.
BUG=None
TEST=cargo test -p ffmpeg &&
cargo test --features "video-decoder,ffmpeg" -p devices video
+ v4l2r test from crosvm book
Change-Id: I77bd32b856afef8538791a99829f7248cd77787e
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3822433
Tested-by: Tatsuyuki Ishi <ishitatsuyuki@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Tatsuyuki Ishi <ishitatsuyuki@google.com>
We're going to use this pattern more in future CLs, so factor it out to
a helper.
BUG=None
TEST=cargo test -p ffmpeg &&
cargo test --features "video-decoder,ffmpeg" -p devices video
+ v4l2r test from crosvm book
Change-Id: Ic20555f8a4ebf0403cc2f933c92bb9bb1d3f51f9
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3822432
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Tatsuyuki Ishi <ishitatsuyuki@google.com>
Tested-by: Tatsuyuki Ishi <ishitatsuyuki@google.com>
The ffmpeg backend requires alignment that is different from 1, so make
a per-backend attribute to handle that.
The other backends inherits the alignment requirement of 1 (noop) from
before.
BUG=None
TEST=cargo test -p ffmpeg &&
cargo test --features "video-decoder,ffmpeg" -p devices video
+ v4l2r test from crosvm book
Change-Id: I5c9f991615f8d66fd055c57a001812a42ea75c71
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3822431
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: Tatsuyuki Ishi <ishitatsuyuki@google.com>
FFmpeg requires buffer alignment in case of SIMD-accelerated codec
implementations. This patch prepares for exposing the
respective requirement in the virtio-video interface.
BUG=None
TEST=cargo build -p ffmpeg
Change-Id: Ia8f3b2987571ddb8cf84b1201019ded83547e8f0
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3822430
Commit-Queue: Tatsuyuki Ishi <ishitatsuyuki@google.com>
Tested-by: Tatsuyuki Ishi <ishitatsuyuki@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
We use an existing virtio command to expose some display data to the
guest system, which currently includes resolution and refresh rate.
EDID contains lots of other fields that are not needed by our graphics
stack, so instead of pulling the exact numbers from the system, we
just use some typical values to fill them.
BUG=b:213149288
TEST=presubmit
Change-Id: I24a5a8c706774bca7e5413b18fc5be3930050168
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3805836
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Pujun Lun <lunpujun@google.com>
Commit-Queue: Pujun Lun <lunpujun@google.com>
Extend pci device's vcfg mmio size frome 4k to 8k, the first page is
trapped by crosvm, the second page is share memory between guest and
crosvm, so that guest could read/write it directly without vm exit.
BUG=b:194391459
TEST=check vcfg mmio size for each pci device
Change-Id: If5ac75b4dc8a829cabce4370e7592f23600e4ef8
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3813136
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Victor Ding <victording@chromium.org>
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Pcie vcfg use similiar pcie ECAM to distribute vcfg mmio into
each pci device, in order to make each pci device has such pcie
vcfg mmio, its size should be same as pcie ECAM.
BUG=b:194391459
TEST=check each device's pcie vcfg mmio in guest
Change-Id: I1ca13384514f323b1e49decd3de198bdfa3ac347
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3813135
Reviewed-by: Victor Ding <victording@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
pcie_cfg_mmio_range has been gotten at the beginning of build_vm,
and its value won't be changed. So later it could be used directly
instead of read_pcie_cfg_mmio() again.
BUG=None
TEST=tools/presubmit
Change-Id: If52843634692bbd9cec7b3679856a3959b41f397
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3813134
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Victor Ding <victording@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
When tbt device is plugged in to the system, there are one or more
pcie switch connected to it. To let host see this topology, this
patch hotplugs all pcie switch to guest along with the endpoint
devices.
BUG=b:199986018
TEST=./tools/presubmit
Change-Id: I46fc365413f0c43fe4362243e60fa74e2ebaa0b0
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3769818
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
This patch adds support for hotplug pcie switch. The user send
HotplugCommand of the new added device with the same order they
appear in device tree, and in handle_hotplug_command we add device
accordingly. During hotplug out, firstly vfio endpoint device will
send hot unplug command, we remove these endpoint device immediate-
ly, and then remove any bridge that is hotplugged into the system
but with zero child device connected to it. When all child bridges
got cleared up and pcie root port have no child devices, we send
plug out interrupt to guest kernel and probe hotplug out handling
in guest.
BUG=b:199986018
TEST=hotplug in and out pcie switch repeatedly
Change-Id: Ic3ab86d14efba4d05e204936e08bc6a582723484
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3769817
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Make the virtio-fs dax BAR prefetchable. This fixes an issue where bar
allocation fails because non-prefetchable bars are now always allocated
from <4GB. Making the bar prefetchable should also have performance
improvements.
BUG=b:241717747
TEST=tast run volteer vm.Fio.virtiofs_dax_randread
Change-Id: I4d06ca25ff5666ba05d75c7fd8c2ec63b10b971f
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3821563
Tested-by: David Stevens <stevensd@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Auto-Submit: David Stevens <stevensd@chromium.org>
