Reworks the way we organize parameters to this module, and
adds CPU manufacturer detection.
BUG=213152505
TEST=builds
Change-Id: Ibb96f08cacbdfdaff5ef971c3d6d7b901b5d73fa
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3690369
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Noah Gold <nkgold@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Our BIOS doesn't set the TSC MSR to 0 on boot, but our hypervisors need
this to be set so they can correctly sync their TSC offsets. This
introduces a generic "reset_msrs" function where we currently reset the
TSC msr, but where we could also reset if we need to in the future.
Cherrypick from downstream branch.
Actual author: Colin Downs-Razouk <colindr@google.com>.
BUG=191981229
TEST=tested downstream
Change-Id: I17b5709411394ae48fb5d7310636636295ebfaad
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3690370
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Noah Gold <nkgold@google.com>
Name the enums instead of bool so that it's easier to reason, and factor
out the MSR loop.
BUG=b:229770963
TEST=build
Change-Id: I7d2306472bdf7482479b40b0ef00f378754a811f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3685671
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Junichi Uekawa <uekawa@chromium.org>
Turbostat detects if CPU frequency and temperature features are
supported by reading several CPUID entries bits. Expose these
CPUID bits to guest when enable-pnp-data option is enabled.
Several MSR registers which turbostat depends on have been already
passed through when ITMT is enabled. Adding code to detect this and
avoid to doubly pass through.
BUG=b:229770963
TEST=Run "turbostat" in Chrome OS guest and show correct value.
Change-Id: Ieebaf616d544cb187a80ec6f3313a246ebf54bb2
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3641466
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
Commit-Queue: Junichi Uekawa <uekawa@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
turbostat shows cpu freq/c-state/thermal statistics data by reading
some related MSRs. Unfortunately some MSRs such as MSR_IA32_POWER_CTL
are already emulated by KVM. The emulated value are not what we want
to expose to Chrome OS guest. KVM_X86_SET_MSR_FILTER ioctl provides
a way to skip KVM's emulation and let user space handle the MSR.
We added two MSR actions "MsrPassthroughFilter" and "MsrEmulateFilter"
to indicate the corresponding MSR needs to be filtered.
BUG=b:229770963
TEST=Run "turbostat" in Chrome OS guest and show correct value.
Change-Id: I5920ddba091589170dc326e10187aec66f75df79
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3641465
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
Commit-Queue: Junichi Uekawa <uekawa@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
This is a reland of commit 129840471d
Original change's description:
> devices: debugcon: add bochs-style debugcon device
>
> This allows for creating a simple write-only debug connection that uses
> a single IO port. This method is supported by both bochs and qemu[1].
>
> The main motivation here is to help in improving crosvm's ability to
> boot OVMF, which makes use of this simple debug device on port 0x402.
> For that one would use `--serial
> type=stdout,hardware=debugcon,debugcon_port=1026` or something similar.
>
> Note that serde_keyvalue doesn't support parsing hex values, hence the
> need to use `1026`, but I intend to address that as well to allow the
> more natural `debugcon_port=0x402` phrasing.
>
> [1]: https://github.com/qemu/qemu/blob/master/hw/char/debugcon.c
>
> BUG=b:233610263
>
> Change-Id: I73238e5c35925668d133bfaa542fcbcf1e28765f
> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3661255
> Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
> Commit-Queue: Mike Gerow <gerow@google.com>
> Tested-by: kokoro <noreply+kokoro@google.com>
Bug: b:233610263
Change-Id: I2f2125da95e8907f4f0c16930952e9b765d33e6c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3671087
Tested-by: kokoro <noreply+kokoro@google.com>
Auto-Submit: Mike Gerow <gerow@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
This reverts commit 129840471d.
Reason for revert: This conflicts with https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3600167 breaking the build
Original change's description:
> devices: debugcon: add bochs-style debugcon device
>
> This allows for creating a simple write-only debug connection that uses
> a single IO port. This method is supported by both bochs and qemu[1].
>
> The main motivation here is to help in improving crosvm's ability to
> boot OVMF, which makes use of this simple debug device on port 0x402.
> For that one would use `--serial
> type=stdout,hardware=debugcon,debugcon_port=1026` or something similar.
>
> Note that serde_keyvalue doesn't support parsing hex values, hence the
> need to use `1026`, but I intend to address that as well to allow the
> more natural `debugcon_port=0x402` phrasing.
>
> [1]: https://github.com/qemu/qemu/blob/master/hw/char/debugcon.c
>
> BUG=b:233610263
>
> Change-Id: I73238e5c35925668d133bfaa542fcbcf1e28765f
> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3661255
> Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
> Commit-Queue: Mike Gerow <gerow@google.com>
> Tested-by: kokoro <noreply+kokoro@google.com>
Bug: b:233610263
Change-Id: Ia70540c3041611f59968cb7929b238eecfe2530d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3671082
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Mike Gerow <gerow@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
This allows for creating a simple write-only debug connection that uses
a single IO port. This method is supported by both bochs and qemu[1].
The main motivation here is to help in improving crosvm's ability to
boot OVMF, which makes use of this simple debug device on port 0x402.
For that one would use `--serial
type=stdout,hardware=debugcon,debugcon_port=1026` or something similar.
Note that serde_keyvalue doesn't support parsing hex values, hence the
need to use `1026`, but I intend to address that as well to allow the
more natural `debugcon_port=0x402` phrasing.
[1]: https://github.com/qemu/qemu/blob/master/hw/char/debugcon.c
BUG=b:233610263
Change-Id: I73238e5c35925668d133bfaa542fcbcf1e28765f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3661255
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Mike Gerow <gerow@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
BIOS expect all the cpus to be pointed at the i386 reset vector before
boot. We can't guarantee that a fresh vcpu will be pointed to the reset
vector by default, so we should set the reset vector when we're
configuring the vcpu when we're using a BIOS.
Cherrypick from downstream branch.
Actual author: Colin Downs-Razouk <colindr@google.com>.
TEST=builds
BUG=b:213152505
Change-Id: Idf4e0a200c8141adf5cbb83856cbd57362d84716
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3657811
Reviewed-by: Colin Downs-Razouk <colindr@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Noah Gold <nkgold@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
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>
