crosvm waits on events like exit, reset, crash, guest panic etc and
uses eventfd to wait on these events. As of now, we have 4 eventfds
and may increase.
This is an attempt to consolidate all Vm events into one framework.
Use Tube instead of Event to get consistent behavior between OSes.
Implement a wrapper over Tube to have a consistent API for events.
BUG=None.
TEST=Built crosvm. Ran a minimal vm to panic and verified that crosvm
received the panic event. cargo test on devices.
Change-Id: I313d428de5e3ce3b879982f913918ec0a4a72c35
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3480577
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Vineeth Pillai <vineethrp@google.com>
Reviewed-by: Noah Gold <nkgold@google.com>
Instead of calling method each time, prepare a list and then iterate
over so that it's clearer we are doing the same thing many times.
BUG=b:215297064
TEST=build
Change-Id: I2556a9c12baa90ac0e5fa98e488e0586b1a4f010
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3653341
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Junichi Uekawa <uekawa@chromium.org>
To simplify the construction and parsing, and put the impossible values
checking at parameter parsing time.
BUG=b:215297064
TEST=build
Change-Id: Ic601d61a73dba9e3ec40f3589c62a586e1c7a8c3
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3655032
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Junichi Uekawa <uekawa@chromium.org>
Some hypervisors (e.g. whpx) require that VM need to initialize their
`CPUID` early i.e. during VM creation. In this case, there is no
per-vcpu initialization of `CPUID`.
Allow this quirk through another entry in `VmCap` that avoids `CPUID`
initialization at vCPU creation time.
BUG=b:213150327
TEST=Compiled.
Change-Id: Ia74434ead1fff244042d03347c82cb73f243bdbb
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3654206
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Vaibhav Nagarnaik <vnagarnaik@google.com>
In order to let host and guest have ths similiar pci mmio layout in
manatee, this commit add a pci-start parameter.
BUG=b:197877871
TEST=boot vm with --pci-start and check vm's mmio layout
Change-Id: I0e83dfb3ab3c3b2ea1b0a1554d532e8414924b36
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3578017
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Junichi Uekawa <uekawa@chromium.org>
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
Remove a few ioports that did nothing, but were specifically wired up to
stubs so they would not generate debug prints.
Port 0xed will only be used by Linux if io_delay=alternate is set on the
cmdline, which was only required for some quirky PC hardware.
Ports 0xf0 ("busy latch reset") and 0xf1 ("coprocessor reset") were only
required by some i386 PC clones without native FPU support.
Dropping this code simplifies the removal of the no_legacy cfg which
will be done by a future change.
BUG=b:223443221
TEST=crosvm run kernel
TEST=crosvm run --bios u-boot.rom --disk kernel
Change-Id: I7b71bd6799759ac3d35be4eb9e157d4eedd9f0c5
Signed-off-by: Alistair Delva <adelva@google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3510981
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Previous pcie cfg mmio is predefined as constand to avoid conflict with pci mmio,
this has two issues:
a. The size of pcie cfg mmio is limited to 64MB, so the max pci bus number is 64.
This isn't ennough for vfio-pci device, as such device's bus number is same as
host bus number, it may be above 64.
b. In manatee, CrOS may be required to have the same pcie cfg mmio base and size
as host.
So this commit add a parameter and let user could specify pcie cfg mmio base and
size. Then the guest memory layout will be adjusted to avoid conflict between
guest ram and pci low mmio.
BUG=b:197877871
TEST=run crosvm with --pcie-ecam=xxxx,xxxx, check vm's memory layout and pcie
ECAM function
Change-Id: I22cf7e2b3f01ab3f48dff9f5246cb1c24faa9703
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3305948
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
When pcie cfg mmio and pci low mmio address could be specified by user,
guest memory layout will be changed to avoid conflict between guest ram,
and pci mmio below 4G. So this commit changes them from constant to
variables, the default value is prefined constand value, but it could
be changed later.
BUG=b:197877871
TEST=tools/presubmit
Change-Id: I5ad1f9d6a050d83ea16a53b926d1fadfac1ed75d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3305947
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
By default PCIE config mmio is above pci low mmio, and they are adjacent.
When user could specify pcie config mmio address and size, the specified
address range will be highly overlap with pci low mmio or guest memory,
then it will split pci low mmio or guest memory. Finally three memory
regions exist in the below 4G space: guest ram, pci low mmio and
pcie config mmio.
In order to simplify memory space management, this commit move pcie
config mmio into pci low mmio, and pcie config mmio is reserved from
pci low mmio at the beginning. In this way, only guest ram and pci
low mmio exist in below 4G space.
BUG=None
TEST=boot a vm and check memory layout below 4G.
Change-Id: I0b253b7bf7fb0287a27a88b34ee28b0a0bd2d172
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3578016
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Now expose running pythcial CPU's max frequency to vCPU to allow intel_
pstate driver to set different CPU priority for task rebalance.
With different CPU priority, ITMT scheduling can really work in Guest.
And remove HWP and ITMT CPUID support from host-cpu-topology.
BUG=b:225375705
TEST=Set `--itmt` and check /proc/sys/kernel/sched_itmt_enabled
Change-Id: I4aa712929fe23b760d8692fed1a55992d1868fc0
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3610842
Commit-Queue: Junichi Uekawa <uekawa@chromium.org>
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Each vcpu has a vcpu->MsrDev file mapping. Instead of trying to create
an instance at first use, just keep an empty map in the beginning.
BUG=b:215297064
TEST=boot volteer-manatee
Change-Id: Ic5a63b0427a6441f190da3917b5f272bbb8ec778
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3611369
Commit-Queue: Junichi Uekawa <uekawa@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Originally, crosvm expose some HWP related CPUID under
'host-cpu-topology', now this is moved under 'itmt' flag.
Before the 'itmt' option is set in initramfs, this may break some freq
related sysfs check. So fix this compatibility issue.
BUG=b:225375705
TEST=boot brya and check cpuinfo_max_freq under sysfs
Change-Id: Iaf7f1590717c12b166d41a0e410a8fd6f605f318
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3609238
Reviewed-by: Lepton Wu <lepton@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Junichi Uekawa <uekawa@chromium.org>
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
This provides at least a minimal one-line description to show what each
crate is about.
BUG=None
TEST=tools/cargo-doc
Change-Id: I26732e8c29062e622d5be09bdc120a49d564b9fd
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3630422
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
No functional changes.
Add trait changes to allow upstreaming hypervisor implementations. This
change differentiates between the hypervisor related data structures
from the VM specific actions to take. The format chosen is using a FnMut
that gets passed to hypervisor handler which contains the VM specific
actions.
BUG=b:213150327
TEST=Compiled crosvm.
Change-Id: I05fde5ff3d6b5f42684c7bfe8a135b6805c9dc06
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3606975
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Vaibhav Nagarnaik <vnagarnaik@google.com>
Add support for injecting an ACPI sleep button event using the command
line. Upon receiving crosvm sleep command, emulate vPM1 accordingly and
trigger vSCI to the guest if ACPI fixed sleep button event is enabled.
Additionally do not mask the ACPI sleep button event in FADT flags for
the guest anymore. Quoting ACPI specification regarding the sleep button
flag: "If the system does not have a sleep button, this value would be
“1” and no sleep button device would be present".
BUG=b:194391015
TEST=Boot the VM, issue "crosvm sleepbtn /run/vm/vm.<hash>/crosvm.sock",
check guest /sys/firmware/acpi/interrupts/ff_slp_btn counter and if vSCI
was injected. With some additional changes (e.g. acpid on the guest)
suspend guest by issuing sleepbtn command from the host.
Change-Id: Ie50a3a781ba4fbfa04da75186fb5549919a5bd68
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3602867
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Grzegorz Jaszczyk <jaszczyk@google.com>
This reverts commit e93b16cefc.
Reason for revert: breaks starting VMs with less than 256 MB of memory (b/230653701)
Original change's description:
> x86_64: Redesign MTRR setting
>
> Currently MTRR setting is: the default cache type is write back and the
> pci low mmio range is uncache, then guest memory is WB by default, but
> pci high mmio and the gap between ram end and pci start below 4G are WB
> also, this part is wrong. In order to fix it, var mtrr should be used to
> set pci high mmio as uncache, but pci high mmio is too large to have
> enough var mtrrs.
>
> This commit change MTRR setting as: the default cache type is uncache,
> and the guest memory is WB. So memory range below 4G and above 4G are
> passed into setup_msrs(). And the variable MTRR registers are limited
> and have base and length requirement, so guest memory size is aligned
> to 256MB to avoid MTRR failure.
>
> BUG=None
> TEST=check guest mtrr setting with different guest memory size
>
> Change-Id: I4c18e83ce5e7fac9ac1bf6e174116a69924184ac
> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3578015
> Tested-by: kokoro <noreply+kokoro@google.com>
> Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
> Commit-Queue: Junichi Uekawa <uekawa@chromium.org>
Bug: None
Change-Id: If183f028da2081ccedbbdc847311cf12081e569d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3612468
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Now the File descriptors aren't stored in MsrHandlers level, for every
passthrough handler, the fd will be refresh in MsrHandlers level.
This can't avoid much File descriptors creation. Fix this error.
BUG=b:225375705
TEST=Set `--userspace-msr=0x1a2,type=r,action=pass,from=cpu0`
Change-Id: I2c67a5c257f545c6469fc71d8b53606256af22c0
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3606974
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Junichi Uekawa <uekawa@chromium.org>
With Intel Turbo Boost Max Technology 3.0, (ITMT), the maximum turbo
frequencies of some cores in a CPU package may be higher than for the
other cores in the same package. In that case, make the scheduler prefer
to run tasks on the CPUs with higher max turbo frequencies, to achieve
better performance.
When vCPUs 1:1 map to pCPUs, ITMT scheduling feature can benefit
performance of Guest. So when user sets `--itmt`, crosvm will check if
`--host-cpu-topology` is set or if `--cpu-affinity` is set for 1:1
mapping.
In kernel, ITMT scheduling feature depends on intel_pstate driver and
ACPI CPPC support.
To setup intel_pstate driver and pass CPPC capability check, we need
emulate related MSRs in userspace:
- MSR_HWP_CAPABILITIES and MSR_TURBO_RATIO_LIMIT: intel_pstate driver
only needs to read. So we passthrough them to Guest. But please note,
to be compatible with the configuration in initramfs, use `FromCPU0`
Temporarily.
- MSR_PM_ENABLE and MSR_HWP_REQUEST: they are MSRs to control HWP.
When intel_pstate driver is initializing, the driver will close/open
HWP by writing into MSR_PM_ENABLE, and the driver also needs to set
performance policy by writing some hints into MSR_HWP_REQUEST.
Note that we don't want Guest's behavior to affect the performance
control of the host, so use 'emulate' handler for them.
- MSR_PLATFORM_INFO: this MSR is emulated in kernel with a fault value
by default. intel_pstate doesn't want this fault value, so we ask
this MSR to exit to userspace and give it a real value.
- MSR_IA32_PERF_CTL: intel_pstate driver use this MSR to set the min
pstate in the initialization. So use 'emulate' handler for this MSR.
Since of `FromCPU0` setting of MSR_HWP_CAPABILITIES, ITMT scheduling
will set the same priority for each core so optimization will not work.
BUG=b:225375705
TEST=Set `--itmt` and check /proc/sys/kernel/sched_itmt_enabled
Change-Id: Icfa85ffa15c3b977c3b62a1f8a379c4c2f5fc49d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3575511
Commit-Queue: Zhao Liu <zhao1.liu@intel.corp-partner.google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
Commit-Queue: Junichi Uekawa <uekawa@chromium.org>
At present, crosvm can support handle RDMSR in userspace by read MSR of
Host directly. This is the RDMSR passthrough in userpace.
This patch adds more MSR handler support, including:
- WRMSR passthrough: write the corresponding MSR of Host directly in
userspace; The control of MSR will work on host;
- RDMSR emulation: crosvm uses a dummy MSR value to let Guest reads on.
This value can be different with real MSR of Host;
- WRMSR emulation: crosvm uses a dummy MSR value to let Guest writes
into. This means the control of MSR won't really work (on Host).
BUG=b:225375705
TEST=Set `--userspace-msr=0x1a2,type=r,action=pass,from=cpu0`
Change-Id: I3276dd651464ef7b695e2ddd433793d59128af9b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3575508
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Junichi Uekawa <uekawa@chromium.org>
Currently MTRR setting is: the default cache type is write back and the
pci low mmio range is uncache, then guest memory is WB by default, but
pci high mmio and the gap between ram end and pci start below 4G are WB
also, this part is wrong. In order to fix it, var mtrr should be used to
set pci high mmio as uncache, but pci high mmio is too large to have
enough var mtrrs.
This commit change MTRR setting as: the default cache type is uncache,
and the guest memory is WB. So memory range below 4G and above 4G are
passed into setup_msrs(). And the variable MTRR registers are limited
and have base and length requirement, so guest memory size is aligned
to 256MB to avoid MTRR failure.
BUG=None
TEST=check guest mtrr setting with different guest memory size
Change-Id: I4c18e83ce5e7fac9ac1bf6e174116a69924184ac
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3578015
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
Commit-Queue: Junichi Uekawa <uekawa@chromium.org>
Simple rename to emphasize that vcpu_ids are not KVM-specific.
Change-Id: Icaf8a5f15a83021cf48467b0b8d0042ab0ab4a92
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3586010
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Steven Moreland <smoreland@google.com>
Update the GDB stub implementation to the 0.6 version of the gdbstub
crate API, attempting to preserve the current behavior as much as
possible. Hardware breakpoints and single stepping still work, but some
existing issues with software breakpoints are still present.
BUG=None
TEST=Manual
Cq-Depend: chromium:3578400
Change-Id: I522242a1a2055ecdf47b2010a615dc9e0136ebd0
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3578025
Tested-by: kokoro <noreply+kokoro@google.com>
Auto-Submit: David LeGare <legare@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
The new specialized functions take IrqEdgeEvent and IrqLevelEvent
arguments, so that callers can use them directly.
BUG=None
TEST=./tools/presubmit
Change-Id: I2c1272e31f6b20eb22743b003bd23b9c1105cda6
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3548066
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dmitry Torokhov <dtor@chromium.org>
Now that we have enough infrastructure in place, we can convert
ACPIPMResource to use IrqLevelEvent for both the host (direct) and guest
SCI handling, which makes the code cleaner.
BUG=None
TEST=./tools/presubmit
Change-Id: Ia3c522a9b143b852bf9c34f62a975b670530a82f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3548065
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dmitry Torokhov <dtor@chromium.org>
crosvm sets up an emulated serial device for ttyS0 as a default device
unless virtio-console is specified.
The setup should be skipped when a vhost-user console is specified as well.
BUG=b:196186396
BUG=b:227407433
TEST=no serial output when one vhost-user console is specified.
Change-Id: Ib17e218fd01a13c109fc1246fd3a6d99031d3181
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3557729
Reviewed-by: Morg <morg@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
This is the revert of 77aa069b67.
At present, when set no_smt, if there are more than 1 logical processor
in a package for Guest, the HTT is set as 0 in CPUID. This does not
comply with the intel SDM specification.
From SDM, HTT indicates:
A value of 0 for HTT indicates there is only a single logical processor
in the package and software should assume only a single APIC ID is
reserved.
In fact, Intel has 2 differnet muti-threading capabilities:
Hyper-Threading Technology and Multi-Core Technology. But with
definition of lastest SDM, HTT flag in CPUID is not equivalent to
Hyper-Threading Technology.
no_smt means disable Hyper-Threading Technology feature so that each
core has 1 logical processor. But with Multi-Core Technology, there
still can be more than 1 logical processors in a package. In this case,
the HTT flag should be set as 1.
BUG=chromium:1304418
TEST=cargo build
TEST=set no_smt and check if there's HT flag in /proc/cpuinfo
Change-Id: Id53320407e247ba61a1ad7cedea8301e1c3469fd
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3545896
Reviewed-by: Vineeth Pillai <vineethrp@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Create the goldfish batter device before ACPIPMResource. This order is
necessary because ACPIPMResource creates a thread, which causes forking
the sandboxed device process to fail.
BUG=none
TEST=boot ARCVM
Change-Id: Iedc84c408eb0e124912dfa411d19b773c1ccc860
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3552477
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Rearrange the code to make sure that if direct GPE feature is used then
it is enforced that both host SCI events and GPE list are supplied when
instantiating ACPIPMResource.
BUG=None
TEST=./tools/presubmit
Change-Id: Ib44e217b09344b1c6bed091312eb196863ca2fee
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3537264
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dmitry Torokhov <dtor@chromium.org>
We make a copy of the data when creating instance of ACPIPMResource, so
let's use slice to pass the data around.
BUG=None
TEST=./tools/presubmit
Change-Id: Idf9627c4ef6aee86fa9de4d1c24ec45aa684432e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3537263
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dmitry Torokhov <dtor@chromium.org>
This reverts commit 052f7df430.
Reason for revert: breaks tast.health.DiagnosticsRun.cpu_cache on volteer-manatee
Original change's description:
> x86_64: remove special-case mappings for direct
>
> 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>
BUG=b:188011323
TEST=tast run health.DiagnosticsRun.cpu_cache
Change-Id: I313620d99726ed185ba2ec04df4413e43a612670
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3537260
Reviewed-by: Anton Romanov <romanton@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
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>
