- 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>
When a vfio pci device is hot-plugged in, its vfio container should be
passed to the virtio-iommu worker for later dynamic mapping/unmapping
requests.
BUG=b:185084350
TEST=Boot a guest, hotplug in and out a vfio-pci
device repeatedly
Change-Id: Ia2a9c9ef4a3ee6399d90aa17c6656acb52647663
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3476650
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Virtio-iommu device can generate viot using pci ranges. After adding a
vfio device, guest can attach this device to virtio-iommu.
BUG=b:185084350
TEST=Boot a guest with vfio device and 'iommu=viommu', another PCI range
node is generated in guest viot.
Change-Id: I9204d8bd341b6e544a62923164d5c8ce46fdd8bf
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3476649
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
A tube channel is needed for the communication between main process and
virtio-iommu worker thread, e.g. passing a vfio container file
descriptor of a hot-pluggable device to the virtio-iommu backend which
is in charge of the mapping/unmapping for the endpoint.
BUG=b:185084350
TEST=Boot a guest with no error
Change-Id: Ib5061e795227040ca400bc9a92df84a27cd26438
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3301703
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Chrome OS does not currently package memoffset-0.6.5 (only 0.6.4), so
building within cros_sdk will fail to find the expected crate. We don't
need any API requirements past what is provided by 0.6, so just request
that. At the same time, upgrade the cros_asyncv2 memoffset from 0.5 to
0.6 so we don't need two separate versions. (The crosvm ebuild was not
requiring a 0.5 version, so this was technically a bug.)
BUG=None
TEST=cargo build
TEST=emerge-hatch crosvm
Change-Id: I2b6c778cdbf57977e6fffd73867e0c4818c44a61
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3502625
Auto-Submit: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Vineeth Pillai <vineethrp@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Add some wrappers to help tame the unruly bindgen anonymous union member
names.
BUG=b:218388029
TEST=cargo build
Change-Id: I4ca5bd9c4d0ae7f60a905a516e8cb5eab761213e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3445532
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Add a framework for bindgen scripts.
This will be filled in when each binding is added in upcoming separate
commits.
BUG=b:218388029
TEST=None
Change-Id: I62363b49d92ceb5b54700589c2329daace7181b8
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3339804
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
When Crosvm receives a KVM_SYSTEM_EVENT_S2IDLE event, it means the
guest VM is entering s2idle suspend state, and it's requesting the
host to put the whole system in the same state.
If hypervisor sends the request on behalf of a privileged VM, Crosvm
can initiate s2idle suspend on the host since it's been granted with
system power management privileges.
BUG=b:199383670
TEST=trigger s2idle from ChromeOS guest
Change-Id: I589a7e1d93abb5ab971fd58de94ee75df48c3c6d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3414635
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dmytro Maluka <dmaluka@google.com>
Commit-Queue: Allen Webb <allenwebb@google.com>
For nonroot vfio-pci device, its prefetchable bars will be allocated
in continuous region, its nonprefetchable bars will be allocated in
another continuous region. Without descending the bar's size, this
allocation waste some mmio.
For example, a vfio-pci device has two non prefetchable bars:
bar0's size is 1M, bar2's size is 8M.
without descending [bar0, bar2], it will allocate 16M mmio, 0~8M
for Bar0, 8~16M for Bar2, although bar0 need 1M only, it occupy 8M
to satisfy bar2's 8M alignment requirement.
With descending [bar2, bar0], it will allocate 9M mmio, 0~8M for
bar2, 8M ~ 9M for bar0.
BUG=b:185084350
TEST=check pcie rp's bridge window in brya-manatee.
Change-Id: I7d93e601f6a46cabe8896aaec065a9dba18c60fa
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3500060
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Bridge window's mmio alignment went wrong during our refactor, fix
it in this commit.
BUG=b:185084350
TEST=Check bridge window and pci device mmio setting in CrOS
Change-Id: Ia1a01d1740f943ec7aa36812defe3aabffcfcbde
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3498219
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
On manatee, a vfio-pci could hotplug into an empty pcie rp when
device's host bus number is in pcie rp's bus range.
But on non-manatee, only one virtual pcie rp is created for device
hot plug, it owns one free bus number only, if a vfio-pci device's
host bus number isn't equal to rp owned bus number, this vfio-pci
device couldn't be added into guest through hotplug, so this commit
change is_match() and allow vfio-pci hotplug onto any empty pcie rp.
BUG=b:185084350
TEST=hot plug in/out a vfio-pci device with host bus_number different from
RP's bus range repeatedly in non-manatee.
Change-Id: I9a1059edd9558683e03d85235e0d164b2aa23672
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3498218
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
This snuck through as our builders were temporarily not checking
clippy in presubmit. See https://crrev.com/c/3498847
BUG=None
TEST=./tools/clippy
Change-Id: I38ca27728ab4e108539407f5499484c2b881dc47
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3499740
Auto-Submit: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Anton Romanov <romanton@google.com>
Commit-Queue: Anton Romanov <romanton@google.com>
Add a flag to the adjust command that allows the command to fail. When
this flag is set, a reply is sent with the balloon size at the end of
adjustment.
The flag also changes the semantics of inflation somewhat. By default,
the balloon driver will indefinitely retry if it fails to allocate pages
during inflation. When the flag is set, the device reacts to puff
failure notifications on the event queue by setting the target num_pages
to the current balloon size, to abort and fail the inflation attempt.
BUG=b:213962590
TEST=manual testing with crrev.com/c/3394436
TEST=check ARCVM balloon still works
Change-Id: Idd606b90550c544ce5bea085f62ac35979679d71
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3394442
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: David Stevens <stevensd@chromium.org>
Manatee doesn't support the guest accessing pages in the balloon, since
that would violate the strict its strict memory accounting, so add an
option to skip setting the deflate-on-oom flag.
However, without deflate-on-oom, the Linux driver normally modifies
MemTotal when inflating/deflating the balloon. To avoid that, this
change adds support for the new responsive-device flag proposed in [1].
[1] https://lists.oasis-open.org/archives/virtio-comment/202201/msg00139.html
BUG=b:214864326
TEST=check ARCVM balloon still works
TEST=manual testing with crrev.com/c/3394436
Change-Id: Iabc8352ee30e1b4a240fa3cad8f3b48ba53699a0
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3471335
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: David Stevens <stevensd@chromium.org>
Implement event queue that was recently proposed upstream [1]. The puff
failure event will be used in a followup CL. The pressure event is
currently ignored. Figuring out how to use it will be done later.
[1] https://lists.oasis-open.org/archives/virtio-comment/202201/msg00139.html
BUG=b:213962590,b:216214118
TEST=check ARCVM balloon still works
Change-Id: Ie1990505da8eda1358f10f24ca3c2b6196303184
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3471334
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: David Stevens <stevensd@chromium.org>
The compiler was warning about a missing `dyn` on the impl block for
PciDevice, which only contained supports_iommu():
warning: trait objects without an explicit `dyn` are deprecated
We could add the `dyn` to fix it, but it seems cleaner to just move the
definition into the VirtioPciDevice impl's existing supports_iommu
function.
Additionally fix up a few clippy warnings about open-coded instances of
map and unnecessary references.
BUG=None
TEST=cargo build # completes without warnings
TEST=tools/presubmit
Fixes: 055b81b295 ("VIRTIO_F_ACCESS_PLATFORM support in virtio-iommu")
Change-Id: I7c923d1663d4f8c958a3c79619a06ab04e1e00ae
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3498843
Reviewed-by: Anton Romanov <romanton@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
A guest VM that is launched with this new option has privileges to
manage some host system resources, for example to get involved with
host power management.
BUG=b:199383670
TEST=start crosvm with and without --privileged-vm option
Change-Id: I8c36f608458047b4189ce5eed6ea527f58fea88d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3414634
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
These may be used by the pVM firmware or bootloader for protected VMs on
Android to indicate the reason why a VM failed to boot, such as a
verification failure, and so we want to have them in the logs for
debugging.
BUG=b:220084045
Change-Id: I449873fb85d590d9e7978a93648e90586ecfff10
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3473452
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Andrew Walbran <qwandor@google.com>
This reverts commit d2d66bc0a4.
Reason for revert: It turns out that adding the first page to the pool
of memory managed by the MMIO allocator has undesired consequences
since crosvm will actually use it for MMIO regions. The first page
has special semantics in other code though, and thus we get stray
accesses to this region, with hard-to-predict consequences.
BUG=b:188011323
TEST=cq
Original change's description:
> system_allocator: allow more than one region to be in the pool
>
> Allows crosvm-direct to have 0-0xfff regions to be mapped.
>
> limitations: Only the first regions gets reflected in the
> pool_base/pool_size.
>
> BUG=b:188011323
> BUG=b:184815519
> TEST=build
>
> Change-Id: I9da3cb2b8d5611068f9323d6ebf62f44162838b4
> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3450017
> Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
> Tested-by: kokoro <noreply+kokoro@google.com>
> Commit-Queue: Junichi Uekawa <uekawa@chromium.org>
Bug: b:188011323
Bug: b:184815519
Change-Id: Ib42b3007662a7a49ad876b83a01f1bb88d09d5f7
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3497136
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Mattias Nissler <mnissler@chromium.org>
Commit-Queue: Mattias Nissler <mnissler@chromium.org>
When a client sends 0-sized data, the device regards that the client
closed the connection and will exit properly.
BUG=b:219674197
TEST=check if no error is shown when a vhost-user blk vmm disconnects
Change-Id: Icd84fb241c39b6dc54a8af41a068a6dd95ce4c2b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3468235
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
