misc: Adapt consistent import style formatting

Historically the Cloud Hypervisor coding style has been to ensure that
all imports are ordered and placed in a single group. Unfortunately
cargo fmt ha

misc: Adapt consistent import style formatting

Historically the Cloud Hypervisor coding style has been to ensure that
all imports are ordered and placed in a single group. Unfortunately
cargo fmt has no support for ensuring that all imports are in a single
group so if whitespace lines were added as part of the import statements
then they would only be odered correctly in the group.

By adopting "group_imports="StdExternalCrate" we can enforce a style
where imports are placed in at most three groups for std, external
crates and the crate itself. Choosing a style enforceable by the tooling
reduces the reviewer burden.

Signed-off-by: Rob Bradford <rbradford@rivosinc.com>

show more ...

hypervisor: Switch to use the new StandardRegisters

With this we are removing the CloudHypervisor definition of
StandardRegisters instead using an enum which contains different
variants of StandardR

hypervisor: Switch to use the new StandardRegisters

With this we are removing the CloudHypervisor definition of
StandardRegisters instead using an enum which contains different
variants of StandardRegisters coming from their bindigs crate.

Signed-off-by: Jinank Jain <jinankjain@microsoft.com>

show more ...

hypervisor: kvm: add missing capability requirements

The list is gathered from going through various code paths in the code
base.

No functional change intended.

Signed-off-by: Wei Liu <liuwe@micro

hypervisor: kvm: add missing capability requirements

The list is gathered from going through various code paths in the code
base.

No functional change intended.

Signed-off-by: Wei Liu <liuwe@microsoft.com>

show more ...

hypervisor: kvm: introduce a check_extension macro

That reduces code repetition.

Signed-off-by: Wei Liu <liuwe@microsoft.com>

hypervisor: kvm: sort the required capabilities

No functional change.

Signed-off-by: Wei Liu <liuwe@microsoft.com>

hypervisor: kvm: drop the check for Cap::SignalMsi

Per the KVM API document, that capability is only valid with in-kernel
irqchip that handles MSIs.

Through out the code base, there is no call to K

hypervisor: kvm: drop the check for Cap::SignalMsi

Per the KVM API document, that capability is only valid with in-kernel
irqchip that handles MSIs.

Through out the code base, there is no call to KVM_IOCTL_SIGNAL_MSI.

Signed-off-by: Wei Liu <liuwe@microsoft.com>

show more ...

build: Bump vmm-sys-util crate and its consumers

This patch bumps the following crates, including `kvm-bindings@0.7.0`*,
`kvm-ioctls@0.16.0`**, `linux-loader@0.11.0`, `versionize@0.2.0`,
`versionize

build: Bump vmm-sys-util crate and its consumers

This patch bumps the following crates, including `kvm-bindings@0.7.0`*,
`kvm-ioctls@0.16.0`**, `linux-loader@0.11.0`, `versionize@0.2.0`,
`versionize_derive@0.1.6`***, `vhost@0.10.0`,
`vhost-user-backend@0.13.1`, `virtio-queue@0.11.0`, `vm-memory@0.14.0`,
`vmm-sys-util@0.12.1`, and the latest of `vfio-bindings`, `vfio-ioctls`,
`mshv-bindings`,`mshv-ioctls`, and `vfio-user`.

* A fork of the `kvm-bindings` crate is being used to support
serialization of various structs for migration [1]. Also, code changes
are made to accommodate the updated `struct xsave` from the Linux
kernel. Note: these changes related to `struct xsave` break
live-upgrade.

** The new `kvm-ioctls` crate introduced breaking changes for
the `get/set_one_reg` API on `aarch64` [2], so code changes are made to
the new APIs.

*** A fork of the `versionize_derive` crate is being used to support
versionize on packed structs [3].

[1] https://github.com/cloud-hypervisor/kvm-bindings/tree/ch-v0.7.0
[2] https://github.com/rust-vmm/kvm-ioctls/pull/223
[3] https://github.com/cloud-hypervisor/versionize_derive/tree/ch-0.1.6

Fixes: #6072

Signed-off-by: Bo Chen <chen.bo@intel.com>

show more ...

hypervisor: Set destination vCPU TSC frequency to source

Include the TSC frequency as part of the KVM state so that it will be
restored at the destination.

This ensures migration works correctly be

hypervisor: Set destination vCPU TSC frequency to source

Include the TSC frequency as part of the KVM state so that it will be
restored at the destination.

This ensures migration works correctly between hosts that have a
different TSC frequency if the guest is running with TSC as the source
of timekeeping.

Fixes: #5786

Signed-off-by: Rob Bradford <rbradford@rivosinc.com>

show more ...

arch, hypervisor: Populate CPUID leaf 0x4000_0010 (TSC frequency)

This hypervisor leaf includes details of the TSC frequency if that is
available from KVM. This can be used to efficiently calculate

arch, hypervisor: Populate CPUID leaf 0x4000_0010 (TSC frequency)

This hypervisor leaf includes details of the TSC frequency if that is
available from KVM. This can be used to efficiently calculate time
passed when there is an invariant TSC.

TEST=Run `cpuid` in the guest and observe the frequency populated.

Fixes: #5178

Signed-off-by: Rob Bradford <robert.bradford@intel.com>

show more ...

hypervisor: simplify LapicState

Both KVM and MSHV share the same layout. We can drop one level of
indirection.

Signed-off-by: Wei Liu <liuwe@microsoft.com>

hypervisor: x86: provide a generic MsrEntry structure

Signed-off-by: Wei Liu <liuwe@microsoft.com>

hypervisor: move away from MsrEntries type

It is a flexible array. Switch to vector and slice instead.

No functional change intended.

Signed-off-by: Wei Liu <liuwe@microsoft.com>

hypervisor x86: provide a generic LapicState structure

This requires making get/set_lapic_reg part of the type.

For the moment we cannot provide a default variant for the new type,
because picking

hypervisor x86: provide a generic LapicState structure

This requires making get/set_lapic_reg part of the type.

For the moment we cannot provide a default variant for the new type,
because picking one will be wrong for the other hypervisor, so I just
drop the test cases that requires LapicState::default().

Signed-off-by: Wei Liu <liuwe@microsoft.com>

show more ...

hypervisor: provide a generic FpuState structure

Signed-off-by: Wei Liu <liuwe@microsoft.com>

hypervisor: provide a generic CpudIdEntry structure

Signed-off-by: Wei Liu <liuwe@microsoft.com>

hypervisor, vmm: move away from CpuId type

CpuId is an alias type for the flexible array structure type over
CpuIdEntry. The type itself and the type of the element in the array
portion are tied to

hypervisor, vmm: move away from CpuId type

CpuId is an alias type for the flexible array structure type over
CpuIdEntry. The type itself and the type of the element in the array
portion are tied to the underlying hypervisor.

Switch to using CpuIdEntry slice or vector directly. The construction of
CpuId type is left to hypervisors.

This allows us to decouple CpuIdEntry from hypervisors more easily.

No functional change intended.

Signed-off-by: Wei Liu <liuwe@microsoft.com>

show more ...

hypervisor: x86: provide a generic SpecialRegisters structure

Signed-off-by: Wei Liu <liuwe@microsoft.com>

hypervisor: x86: provide a generic DescriptorTable structure

Signed-off-by: Wei Liu <liuwe@microsoft.com>

hypervisor: x86: provide a generic SegmentRegister structure

And drop SegmentRegisterOps since it is no longer required.

Signed-off-by: Wei Liu <liuwe@microsoft.com>

hypervisor: x86: provide a generic StandardRegisters structure

We only need to do this for x86 since MSHV does not have aarch64 support
yet. This reduces unnecessary code churn.

Signed-off-by: Wei

hypervisor: x86: provide a generic StandardRegisters structure

We only need to do this for x86 since MSHV does not have aarch64 support
yet. This reduces unnecessary code churn.

Signed-off-by: Wei Liu <liuwe@microsoft.com>

show more ...

hypervisor: turn boot_msr_entries into a trait method

This allows dispatching to either KVM or MSHV automatically.

No functional change.

Signed-off-by: Wei Liu <liuwe@microsoft.com>

cargo: Clean up serde dependencies

There is no need to include serde_derive separately,
as it can be specified as serde feature instead.

Signed-off-by: Maksym Pavlenko <pavlenko.maksym@gmail.com>

vmm: Ensure that PIO and MMIO exits complete before pausing

As per this kernel documentation:

For KVM_EXIT_IO, KVM_EXIT_MMIO, KVM_EXIT_OSI, KVM_EXIT_PAPR, KVM_EXIT_XEN,
KVM_EXIT_EPR, KV

vmm: Ensure that PIO and MMIO exits complete before pausing

As per this kernel documentation:

For KVM_EXIT_IO, KVM_EXIT_MMIO, KVM_EXIT_OSI, KVM_EXIT_PAPR, KVM_EXIT_XEN,
KVM_EXIT_EPR, KVM_EXIT_X86_RDMSR and KVM_EXIT_X86_WRMSR the corresponding
operations are complete (and guest state is consistent) only after userspace
has re-entered the kernel with KVM_RUN. The kernel side will first finish
incomplete operations and then check for pending signals.

The pending state of the operation is not preserved in state which is
visible to userspace, thus userspace should ensure that the operation is
completed before performing a live migration. Userspace can re-enter the
guest with an unmasked signal pending or with the immediate_exit field set
to complete pending operations without allowing any further instructions
to be executed.

Since we capture the state as part of the pause and override it as part
of the resume we must ensure the state is consistent otherwise we will
lose the results of the MMIO or PIO operation that caused the exit from
which we paused.

Fixes: #3658

Signed-off-by: Rob Bradford <robert.bradford@intel.com>

show more ...

hypervisor: Add support for setting KVM identity map

Extending the Vm trait with set_identity_map_address() in order to
expose this ioctl to the VMM.

Signed-off-by: Sebastien Boeuf <sebastien.boeuf

hypervisor: Add support for setting KVM identity map

Extending the Vm trait with set_identity_map_address() in order to
expose this ioctl to the VMM.

Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>

show more ...

arch, hypervisor, vmm: Explicitly place the TSS in the 32-bit space

Place the 3 page TSS at an explicit location in the 32-bit address space
to avoid conflicting with the loaded raw firmware.

Signe

arch, hypervisor, vmm: Explicitly place the TSS in the 32-bit space

Place the 3 page TSS at an explicit location in the 32-bit address space
to avoid conflicting with the loaded raw firmware.

Signed-off-by: Rob Bradford <robert.bradford@intel.com>

show more ...