Wire up GPE eventfd forwarding and crosvm's GPE emulation.
This patch allows to provide ACPIPMResource with the list of GPEs
which should work as direct physical (passthrough) GPEs rather than
purely emulated ones.
BUG=b:205072342
TEST=see CL:3492224
Change-Id: Idb8ef36299c793f56d73246d15ff89f495bb30ef
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3492223
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Tomasz Nowicki <tnowicki@google.com>
In order to allow handling physical GPE in the guest, implement GPE
status & enable register bits read/write passthrough to/from physical
registers for selected GPEs (while for the rest of GPEs the registers
remain purely emulated).
We use Linux kernel's ACPI sysfs interface for accessing physical
GPE regs. Note that in particular for enabling/disabling GPEs we use
"mask"/"unmask" interfaces instead of "enable"/"disable", since we
want to do raw enable/disable, bypassing ACPICA's reference counting.
We only do "enable" when it is enabled for the first time, to ensure
that the ref count for the given GPE is > 0.
This of course assumes that the given GPE is enabled/disabled
exclusively by the guest, never by the host.
Thanks to Peter Fang for the idea to use mask/unmask.
BUG=b:205072342
TEST=see CL:3492224
Change-Id: I20c08d371710f89b359ac5e8677f22165811eb84
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3492222
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dmytro Maluka <dmy@semihalf.com>
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Commit-Queue: Tomasz Nowicki <tnowicki@google.com>
In order to allow handling physical GPE in the guest, implement
physical SCI interrupts forwarding from the host to the guest.
It uses an eventfd based mechanism similar to how we normaly do
forwarding of other level-triggered interrupts. The difference is that
SCI trigger events from kernel are not injected directly to irqchip.
In order to support injecting both physical and virtual SCI interrupts
(so that some GPEs can be handled as physical while other GPEs can be
emulated), SCI trigger event is intercepted by ACPIPMResource which
injects it to irqchip via another eventfd - the same eventfd which is
used for injecting virtual SCI interrupts.
Similarly, resample event for physical forwarded SCI is received
via the same eventfd as for virtual SCI, then forwarded back to kernel.
BUG=b:205072342
TEST=see CL:3492224
Change-Id: I480a3000d69305aabc777e193d3453c476d2dbbd
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3492221
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dmytro Maluka <dmy@semihalf.com>
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Commit-Queue: Tomasz Nowicki <tnowicki@google.com>
In order to ensure proper emulation of PM1 and GPE events for the guest
and prevent lost events, upon receiving SCI resample event we need to
trigger SCI interrupt again if the status of some of the virtual PM1 or
GPE events is still not cleared, i.e. if:
a. the guest has received the last PM1 or GPE event but hasn't cleared
it for some reason.
or
b. the guest hasn't received the last PM1 or GPE event because it was
processing the previous SCI (i.e. SCI was masked in the guest).
BUG=b:205072342
TEST=inject GPE or power button event from command line
and inspect /sys/firmware/acpi/interrupts/
Change-Id: Iff9f9812328823b1876721fbb4be9d0e937f2737
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3492219
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Tomasz Nowicki <tnowicki@google.com>
When pci_low_mmio allocates non-prefetchable bridge window for virtual
pcie root ports on brya-manatee, out of space error happens on one
virtual pcie root port.
Currently 756MB mmio is reaserved for pci low mmio and nearly 650MB could
be allocated, but byra has three pcie root ports, each pcie root port
reserve 194MB non-prefetchable bridge, so CrOS in brya-manatee needs at
least 194x3=582MB pci low mmio, consider bar alignment, 756MB isn't
enough for brya-manatee and the above error happen, so this commit
increate it to 1G.
BUG=b:185084350
TEST=boot brya-manatee and check bridge window allocation on each
virtual pcie root port.
Change-Id: I837f7dad459f624437ce6334719dfe337dea1d75
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3535683
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
There is currently no use case for the PM timer in the guest and TMR_STS
is not implemented in vPM1, so disable it altogether for now.
BUG=b:199383670
TEST=boot manatee
Change-Id: I61b214a466becef2d923fdbfe450c31b08b70037
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3528533
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
KVM irqchip treats differently edge vs level triggered IRQ.
By registering SCI without resample event, we might see unexpected
misbehavior. Since SCI is level-triggered IRQ pass corresponding
resample event even though we don't utilize it right now.
Also store the new event as part of ACPIPMResource for future usage.
BUG=b:205072342
TEST=inject GPE and inspect /sys/firmware/acpi/interrupts/
Change-Id: Ib27f98bbef56ea4ca18da5bf4428bf45bf115882
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3439888
Reviewed-by: Micah Morton <mortonm@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Commit-Queue: Grzegorz Jaszczyk <jaszczyk@google.com>
Linux expects that PCI bars lie within a compatible bridge window, which
are typically specified via _CRS objects in ACPI. This change adds an
option to restrict mmio allocations (i.e. PCI bars) to within a
specified set of ranges. The specified set of ranges is intersected with
the default mmio allocation ranges generated by the crosvm arch code to
produce the final mmio allocation ranges.
This change is required to remove pci=nocrs from the CrOS guest's kernel
command line flags. Removing that flag is a prerequisite for enabling
virtio-iommu, since without the configuration information from ACPI, the
kernel reserves all IOVAs in iova_reserve_pci_windows.
BUG=b:181736020
TEST=boot manatee w/o pci=nocrs kernel cmdline flag
TEST=tast run trogdor|hatch arc.Boot.vm
Change-Id: I0a096420c5d5ef56dd76021951968e264ce40f42
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3499900
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: David Stevens <stevensd@chromium.org>
Add a method to SystemAllocator that returns a vector of all pools and
use it to generate the PCI ranges in build_vm. This also fixes a bug
where x86 used the size as the end address for the high_mmio region.
BUG=b:181736020
TEST=tast run trogdor|hatch arc.Boot.vm
Change-Id: Id4a300ec61c15bc08fb069b80428b22461ca935b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3516668
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: David Stevens <stevensd@chromium.org>
Remove the ramoops region from high_mmio when constructing the system
allocator. This means the aarch64 code no longer needs to manually
adjust high_mmio when determining the pci regions.
BUG=b:181736020
TEST=Check arcvm pstore still works
Change-Id: I81ca398a1984f0efb30c0a4d4b620bd50fe9df85
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3516667
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: David Stevens <stevensd@chromium.org>
Have the arch code return the SystemAllocatorConfig instead of a
SystemAllocator. This will be used to allow the core code to apply
additional restrictions on top of the arch code's restrictions.
BUG=b:181736020
TEST=compiles
Change-Id: I4d9ca277f039586e664648492c8744967dcd2ee5
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3516665
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: David Stevens <stevensd@chromium.org>
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>
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>
- 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>
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 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>
Adding some conditional compilation flags so we do not need to
exclude them on each test run. None of there actually increase
the number of tests run, but gets us closer to being able
to run `cargo test --workspace`
BUG=b:218374759
TEST=./tools/presubmit --all
Change-Id: I181a84847fc09a4e1a6fb2b5f21538ebc400d607
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3453046
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Fixed ACPI Description Table (FADT) contains Low Power S0 Idle Capable
Flag. This commit introduces "--s2idle" argument allowing to set proper
bit in the guest FADT table. This is required to inform guest OS to use
s2idle instead of traditional S3 power mode.
BUG=b:194391015
TEST=Build crosvm and run "crosvm run --s2idle ..", dump FADT table and
confirm that proper flag was set.
Change-Id: I243bfe2cc4840278fcdbf33dcb147b2eda50856d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3457402
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Grzegorz Jaszczyk <jaszczyk@google.com>
Run tests for sys_util_core, poll_token_derive and balloon_control on
windows.
Using dotfiles to disable/serialize test runs of a subset of crates does
not work well with third party crates as it forces us to commit the dot
file to the crate.
The patch modifies and uses the script that runs linux tests.
This patch also allows us to
- build/test child crate even if parent crate has disabled build/test.
- avoid building crosvm if it is not explicitly specified.
RIP short lived .windows_build_test_skip. You allowed us to run noop
kokoro tests.
Test: py .\tools\impl\test_runner.py --arch x86_64
Bug: b:215610772
Change-Id: Icc6d04ffd7c0c33d4f60aeac16fc7d23881c387d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3459809
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Vikram Auradkar <auradkar@google.com>
io ports is a 16 bit thing, check that it is actually 16 bits and fix
the parameters.
BUG=None
TEST=read intel SDM, run crosvm test
Change-Id: I50b6d5593b0699317ac2f852836208a46240714b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3470601
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Junichi Uekawa <uekawa@chromium.org>
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>
In preparation to allow multiple low memory regions to be passed on, I wanted to
make initialization simpler.
Introduce `MemRegion` struct instead of tuple to help me understand it is a base
and size.
BUG=b:188011323
TEST=build
Change-Id: Ie8b54354a25c478d5ad0a0185b7e07d28840dd87
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3439666
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Junichi Uekawa <uekawa@chromium.org>
The bindings need to be regenerated. Just disable warnings for now.
BUG=b:192373803
TEST=./tools/presubmit
Change-Id: Ia34638cbc20c4705631ea3693d4476137ebf8d55
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3439051
Reviewed-by: Noah Gold <nkgold@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
crosvm seems to be adding an extra mptable entry for irq0 that points to
a non-existent ioapic (with apic_id=0 where the ioapic's id is not 0).
The bad irq0 and valid irq0 entries are the first two listed when using
apic=debug and show_lapic=all kernel params:
```
[ 0.756044] Int: type 0, pol 0, trig 0, bus 01, IRQ 00, APIC ID 0, APIC INT 00
[ 0.764474] Int: type 0, pol 0, trig 0, bus 01, IRQ 00, APIC ID 5, APIC INT 00
```
If the bad irq0 entry exists, and if check_timer is called in io_apic.c
in the kernel, it can cause an invalid opcode exception in some kernels,
seemingly because it ends up calling find_irq_entry(-1, -1, 0) which
does a -1 index on the static "ioapics" struct in io_apic.c. It seems
like a kernel bug that such an index could happen, but this also seems
like a bad entry in mptables.
A similar irq entry exists in kvmtool, but it it's a local interrupt. If
this entry is adjusted to match then the invalid opcode kernel panic
stops.
BUG=b:211912415
TEST=ran linux image, booted fine
Change-Id: I125dd2458f86de65553577b8d1c4d1366d778de9
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3405332
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Colin Downs-Razouk <colindr@google.com>
The patch also adds files to skip building and testing crates on
windows. When we run
```
tools/windows/build_test.py --skip_file_name .windows_build_test_skip
```
the build/test succeeds without actually doing anything as build/test
for all crates is skipped by creating '.windows_build_test_skip'.
Bug: 213170957
Test: Ran script on downstream repo
Change-Id: Iebd2cea463ee722be4feaed88229e1fb5e9fd6c5
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3417918
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Vikram Auradkar <auradkar@google.com>
Let's pass host's processor brand string to guests, so that lscpu and
/proc/cpuinfo do not fall back to printing numeric model numbers
but rather print vendor string, such as:
Intel(R) Core(TM) i3-10110U CPU @ 2.10GHz
or
AMD Ryzen 3 3250C 15W with Radeon Graphics
BUG=None
TEST=boot zork and hatch, examine lscpu in crostini
Change-Id: I7cd3ccd4a6328695cc180ee4c13d19d2e48f3def
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3410647
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dmitry Torokhov <dtor@chromium.org>
The high MMIO region of the system allocator was previously set up with
the upper limit of 2**64 - 1, but physical addresses on actual systems
are not that large. Now that pmem allocates from the upper end of the
high MMIO region, the size of the allocator actually matters.
Limit the aarch64 high MMIO allocator to the VM's physical address size
so that addresses at the end of the allocation range are usable and pmem
devices can be created on aarch64.
BUG=b:210727578
TEST=Boot with pmem device on aarch64
Change-Id: I67962c2b03f0f265349ae889c988eb69ef526f4a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3366858
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Andrew Walbran <qwandor@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Add a function that returns the size of guest physical addresses. This
wraps KVM_CAP_ARM_VM_IPA_SIZE on aarch64 and CPUID to query host
physical address size on x86_64. This replaces the phy_max_address_bits
function from x86_64, and all callers are migrated to use the new Vm
function instead.
BUG=b:210727578
TEST=check on trogdor64 with debug prints
Change-Id: I3107fe6357fcf166b7ad0e2a7c55919705da3b0c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3364971
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Andrew Walbran <qwandor@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
This involves two main changes:
* Protected VMs must be created with KVM_VM_TYPE_ARM_PROTECTED.
* pVM firmware is now loaded by IPA rather than memslot ID.
There are also a lot of trivial changes because the ProtectionType enum
was moved from the devices crate to the hypervisor crate.
BUG=b:209794844
TEST=Will tested manually with patched kernel and dummy firmware
Change-Id: I1dd75e20063ca4736f155292ca5f70b94664fdd9
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3330204
Auto-Submit: Andrew Walbran <qwandor@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
At present, host-cpu-topology won't set HT flag for vCPU.
It's reasonable to allow Guest have the same HT flag setting as Host
when set host-cpu-topology.
BUG=None
TEST=cargo build
TEST=set host-cpu-topology and check ht flag in /proc/cpuinfo
Change-Id: I116e49975ab32d37c733690bc0f0f96148fbd4f6
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3314869
Reviewed-by: David Stevens <stevensd@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
At present, if no_smt is set, the cpus of Guest still has the HT flag.
To fix this issue, won't set HT flag in Guest's CPUID if no_smt is set.
BUG=None
TEST=cargo build
TEST=set no_smt and check if there's HT flag in /proc/cpuinfo
Change-Id: I8a986867f272face39253b523462dc8a26ab479c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3314868
Reviewed-by: David Stevens <stevensd@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Mattias Nissler <mnissler@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
At present, when set host-cpu-topology option, the Guest still can't
get the hybrid information.
Now, for ADL, the hybrid related info is needed. These info include the
hybrid part flag (bit 15) in leaf 7 of CPUID, the core type and native
model id in leaf 1A of CPUID.
BUG=None
TEST=cargo build
TEST=Check the CPUID dump of Guest and Host
Change-Id: Icc03bc50160fdffc221e992d90225e7ed8081e8d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3314867
Reviewed-by: David Stevens <stevensd@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
The correct offset for the reset value in FADT is 128.
BUG=b:3169569
TEST=Build and boot.
Change-Id: If8bb9dc4218261464ce6100456c1386c3abb3936
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3336217
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dmitry Torokhov <dtor@chromium.org>
Seems like it's not used anymore.
BUG=None
TEST=cargo test --features=direct # has less warnings.
Change-Id: Id53f89a89c8e2aa8755394503aac8e773e785c54
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3327806
Auto-Submit: Junichi Uekawa <uekawa@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Junichi Uekawa <uekawa@chromium.org>
In order to comply with kernel E820Type definition and make code more
readable, this commit changes E820Type from constants to enum.
BUG=None
TEST=tools/presubmit
Change-Id: I514a3f71c734305c19cebbca6844f09d1fb16dab
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3314866
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Since _OSC is added, OS could negotiate any pcie features with firmware
through _OSC, so remove "pcie_ports=native" parameter from command line.
BUG=b:197877871
TEST=check pcie native hotplug compability in VM
Change-Id: Iba363aa0d5c6acaf61d72ed9cc4697677f9ace6c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3305946
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
OS call acpi _OSC method to request control for PCIE natvie features like
pcie hotplug, pcie advanced error report, pcie PME. But currently crosvm
lack of _OSC method, so OS couldn't enable these pcie features.
This commit add _OSC method, enable pcie hotplug and pcie cap structure
control, but disable SHPC hotplug, pcie PME and pcie AER.
BUG=b:197877871
TEST=Check pcie hotplug capability in VM
Change-Id: If4b6c8026c312ebfdeb18df7c0673571e3e9b631
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3305945
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Intel acpi method reads PCIEBAR Base Address Register in host bridge to
get the pcie config mmio base address. This commit emulates this
register, so the acpi method could get the right information.
BUG=b:197877871
TEST=Verify this regsiter's value in a vm
Change-Id: I93bf8e678acc0e085b102a2eb3a88cbf466aed78
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3305944
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Junichi Uekawa <uekawa@chromium.org>
In order to enable pcie enhanced configurtion access mechanism in kernel,
acpi mcfg table is mandatory. So kernel could know the base and size of
pcie enhanced configuration access mmio.
BUG=b:197877871
TEST=Boot a vm and r/w pci config regiser through pcie ECAM
Change-Id: Icecedba3f31cd94bed76e48932c5e77f56effb9c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3305943
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Junichi Uekawa <uekawa@chromium.org>
Since PciRoot has been modified into Arc<Mutex<>>, RunnableLinuxVm->root_config
could be changed from PciConfigArch to PciRoot also, this could simplify code
and reduce two functions from PciConfigArch.
BUG=b:197877871
TEST=tools/presubmit
Change-Id: Ibc18587900d6f8259ac1d6f8fe7b3ea4fedad07e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3305942
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Junichi Uekawa <uekawa@chromium.org>
Now that we have wired up PCI reset and exposed it via ACPI reset
register we no longer need to force resetting via keyboard port.
BUG=b:3169569
TEST=Reboot mantee board
Change-Id: I4bc02909199b3f519993794e28ed742432ebd64b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3317156
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dmitry Torokhov <dtor@chromium.org>
Instead of returning 0 for both shutdown and reset/reboot, let's have
shutdown continue returning 0, but reset will now return 32 exit code,
so that callers will have an option to handle this case differently.
BUG=b:3169569
TEST=Examine crosvm exit codes when resetting and shutting down VM
Change-Id: I2c7c11b7f8c8528744f7e25e5d17c6fa9810f409
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3316835
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dmitry Torokhov <dtor@chromium.org>
