hypervisor: emulator: Move MockVMM into a shared test module

The MockVMM platform will be used by other instructions emulation
implementations, but also by the emulator framework.

Signed-off-by: Sa

hypervisor: emulator: Move MockVMM into a shared test module

The MockVMM platform will be used by other instructions emulation
implementations, but also by the emulator framework.

Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>

show more ...

hypervisor: x86: only calculate address when necessary in MOV emulation

Only calculate the address when the operand is memory.

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

hypervisor: x86: drop an extraneous box indirection

There is no need to put a box into another box.

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

hypervisor: x86: reference PlatformEmulator in Emulator

The observation here is PlatformEmulator can be seen as the context for
emulation to take place. It should be rather easy to construct a conte

hypervisor: x86: reference PlatformEmulator in Emulator

The observation here is PlatformEmulator can be seen as the context for
emulation to take place. It should be rather easy to construct a context
that satisfies the lifetime constraints for instruction emulation.

The thread doing the emulation will have full ownership over the
context, so this removes the need to wrap PlatformEmulator in Arc and
Mutex, as well as the need for the context to be either Clone or Copy.

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

show more ...

hypervisor: x86: handle more registers in emulator

List all GPRs documented in Intel's SDM.

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

hypervisor: x86: Add MOV to the emulator instruction map

Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>

hypervisor: x86: Emulate MOV

And add a few unit tests based on a Mock platform.

Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>

hypervisor: x86: Add an instruction emulator

The emulator gets a CPU state from a CpuStateManager instance, emulates
the passed instructions stream and returns the modified CPU state.

The emulator

hypervisor: x86: Add an instruction emulator

The emulator gets a CPU state from a CpuStateManager instance, emulates
the passed instructions stream and returns the modified CPU state.

The emulator is a skeleton for now since it comes with an empty
instruction mnemonic map.

Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>

show more ...

hypervisor: x86: Add an InstructionHandler interface

And an InstructionMap helper structure to map x86 mnemonic codes
to instruction handlers.

Any instruction emulation implementation should then b

hypervisor: x86: Add an InstructionHandler interface

And an InstructionMap helper structure to map x86 mnemonic codes
to instruction handlers.

Any instruction emulation implementation should then boil down with
implementing InstructionHandler for any supported mnemonic.

Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>

show more ...

hypervisor: x86: Add a minimal CpuStateManager implementation

Minimal will be defined by the amount of emulated instructions.
Carrying all GPRs, all CRs, segment registers and table registers should

hypervisor: x86: Add a minimal CpuStateManager implementation

Minimal will be defined by the amount of emulated instructions.
Carrying all GPRs, all CRs, segment registers and table registers should
cover quite a few instructions.

Co-developed-by: Wei Liu <liuwe@microsoft.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>

show more ...

hypervisor: x86: Add a CpuStateManager interface

For efficiently emulating x86 instructions, we need to build and pass a
CPU state copy/reference to instruction emulation handlers. Those handlers
wi

hypervisor: x86: Add a CpuStateManager interface

For efficiently emulating x86 instructions, we need to build and pass a
CPU state copy/reference to instruction emulation handlers. Those handlers
will typically modify the CPU state and let the caller commit those
changes back through the PlatformEmulator trait set_cpu_state method.

Hypervisors typically have internal CPU state structures, that maps back
to the correspinding kernel APIs. By implementing the CpuState trait,
instruction emulators will be able to directly work on CPU state
instances that are directly consumable by the underlying hypervisor and
its kernel APIs.

Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>

show more ...

hypervisor: Architecture agnostic instruction emulation interface

In order to emulate instructions, we need a way to get access to some of
the guest resources. The PlatformEmulator interface provide

hypervisor: Architecture agnostic instruction emulation interface

In order to emulate instructions, we need a way to get access to some of
the guest resources. The PlatformEmulator interface provides guest
memory and CPU state access to emulator implementations.

Typically, an hypervisor will implement PlatformEmulator for architecture
specific instruction emulators to build their framework on top of.

Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>

show more ...

arch: Move the gdt module to the hypervisor crate

We will need the GDT API for the hypervisor's x86 instruction
emulator implementation, it's better if the arch crate depends on the
hypervisor one r

arch: Move the gdt module to the hypervisor crate

We will need the GDT API for the hypervisor's x86 instruction
emulator implementation, it's better if the arch crate depends on the
hypervisor one rather than the other way around.

Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>

show more ...

hypervisor, vmm: Remove shared ownership of VmmOps

This interface is used by the vCPU thread to delegate responsibility for
handling MMIO/PIO operations and to support different approaches than a
VM

hypervisor, vmm: Remove shared ownership of VmmOps

This interface is used by the vCPU thread to delegate responsibility for
handling MMIO/PIO operations and to support different approaches than a
VM exit.

During profiling I found that we were spending 13.75% of the boot CPU
uage acquiring access to the object holding the VmmOps via
ArcSwap::load_full()

13.75% 6.02% vcpu0 cloud-hypervisor [.] arc_swap::ArcSwapAny<T,S>::load_full
|
---arc_swap::ArcSwapAny<T,S>::load_full
|
--13.43%--<hypervisor::kvm::KvmVcpu as hypervisor::cpu::Vcpu>::run
std::sys_common::backtrace::__rust_begin_short_backtrace
core::ops::function::FnOnce::call_once{{vtable-shim}}
std::sys::unix::thread::Thread::new::thread_start

However since the object implementing VmmOps does not need to be mutable
and it is only used from the vCPU side we can change the ownership to
being a simple Arc<> that is passed in when calling create_vcpu().

This completely removes the above CPU usage from subsequent profiles.

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

show more ...

hypervisor: Add ability to get dirty logged pages

Return a bitmap of pages that have been dirtied (written to) since it
was last called.

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

hypervisor: Add control for dirty page logging

When creating a userspace mapping provide a control for enabling the
logging of dirty pages.

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

hypervisor: kvm: Correctly share VmmOps between Kvm{Vm,Vcpu}

Cloning the ArcSwapOption (like the ArcSwap) does not act like a
.clone() on an Arc, instead an entirely new ArcSwap is created with the

hypervisor: kvm: Correctly share VmmOps between Kvm{Vm,Vcpu}

Cloning the ArcSwapOption (like the ArcSwap) does not act like a
.clone() on an Arc, instead an entirely new ArcSwap is created with the
same contents. To correctly share the ArcSwap needs to be placed inside
an Arc.

See: https://github.com/vorner/arc-swap/commit/2433d5719be341dc520a8bb93d9d3ce7f141a80d#diff-6c6d94533c44c19bd1416ef17bad1a878e63dca6e98d59181228fbe8f967c62bR6

Due to this being wrongly used ::clone() was removed from
ArcSwap/ArcSwapOption in 1.0.0.

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

show more ...

vmm: Implement VM rebooting on AArch64

The logic to handle AArch64 system event was: SHUTDOWN and RESET were
all treated as RESET.

Now we handle them differently:
- RESET event will trigger Vmm::vm

vmm: Implement VM rebooting on AArch64

The logic to handle AArch64 system event was: SHUTDOWN and RESET were
all treated as RESET.

Now we handle them differently:
- RESET event will trigger Vmm::vm_reboot(),
- SHUTDOWN event will trigger Vmm::vm_shutdown().

Signed-off-by: Michael Zhao <michael.zhao@arm.com>

show more ...

vmm, hypervisor: Fix snapshot/restore for Windows guest

The snasphot/restore feature is not working because some CPU states are
not properly saved, which means they can't be restored later on.

Firs

vmm, hypervisor: Fix snapshot/restore for Windows guest

The snasphot/restore feature is not working because some CPU states are
not properly saved, which means they can't be restored later on.

First thing, we ensure the CPUID is stored so that it can be properly
restored later. The code is simplified and pushed down to the hypervisor
crate.

Second thing, we identify for each vCPU if the Hyper-V SynIC device is
emulated or not. In case it is, that means some specific MSRs will be
set by the guest. These MSRs must be saved in order to properly restore
the VM.

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

show more ...

hypervisor: kvm: aarch64: Trigger reset upon KVM_SYSTEM_EVENT_RESET

This will trigger Vm::vm_reboot to make the VM reboot.

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

hypervisor: kvm: Use unstable_sort() to keep clippy happy

"Using a stable sort consumes more memory and cpu cycles. Because values
which compare equal are identical, preserving their relative order

hypervisor: kvm: Use unstable_sort() to keep clippy happy

"Using a stable sort consumes more memory and cpu cycles. Because values
which compare equal are identical, preserving their relative order (the
guarantee that a stable sort provides) means nothing, while the extra
costs still apply."

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

show more ...

hypervisor, arch: rename "OneRegister" and relevant code

The OneRegister literally means "one (arbitrary) register". Just call it
"Register" instead. There is no need to inherit KVM's naming scheme

hypervisor, arch: rename "OneRegister" and relevant code

The OneRegister literally means "one (arbitrary) register". Just call it
"Register" instead. There is no need to inherit KVM's naming scheme in
the hypervisor agnostic code.

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

show more ...

aarch64: Add OneReg to the list required extensions for KVM

Without that capability save / restore for aarch64 won't work.

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

hypervisor, vmm: Introduce VmmOps trait

Run loop in hypervisor needs a callback mechanism to access resources
like guest memory, mmio, pio etc.

VmmOps trait is introduced here, which is implemented

hypervisor, vmm: Introduce VmmOps trait

Run loop in hypervisor needs a callback mechanism to access resources
like guest memory, mmio, pio etc.

VmmOps trait is introduced here, which is implemented by vmm module.
While handling vcpuexits in run loop, this trait allows hypervisor
module access to the above mentioned resources via callbacks.

Signed-off-by: Praveen Paladugu <prapal@microsoft.com>
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>

show more ...

hypervisor, vmm: fix clippy warnings

Signed-off-by: Praveen Paladugu <prapal@microsoft.com>