5bd63efa | 27-Nov-2020 |
Samuel Ortiz <sameo@linux.intel.com> |
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 ...
|
66b00166 | 26-Nov-2020 |
Wei Liu <liuwe@microsoft.com> |
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> |
c6aea5af | 26-Nov-2020 |
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> |
c8b65549 | 25-Nov-2020 |
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 ...
|
a6ad85dc | 25-Nov-2020 |
Wei Liu <liuwe@microsoft.com> |
hypervisor: x86: handle more registers in emulator
List all GPRs documented in Intel's SDM.
Signed-off-by: Wei Liu <liuwe@microsoft.com> |
0f4f30db | 19-Nov-2020 |
Samuel Ortiz <sameo@linux.intel.com> |
hypervisor: x86: Add MOV to the emulator instruction map
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> |
fe540122 | 19-Nov-2020 |
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> |
12b7a498 | 19-Nov-2020 |
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 ...
|
1fc97e91 | 19-Nov-2020 |
Samuel Ortiz <sameo@linux.intel.com> |
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 ...
|
fc5d6c96 | 24-Nov-2020 |
Samuel Ortiz <sameo@linux.intel.com> |
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 ...
|
546778eb | 13-Nov-2020 |
Samuel Ortiz <sameo@linux.intel.com> |
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 ...
|
f0360aff | 13-Nov-2020 |
Samuel Ortiz <sameo@linux.intel.com> |
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 ...
|
ae96aeda | 13-Nov-2020 |
Samuel Ortiz <sameo@linux.intel.com> |
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 ...
|
0fec3265 | 18-Nov-2020 |
Rob Bradford <robert.bradford@intel.com> |
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 ...
|
041724a7 | 11-Nov-2020 |
Rob Bradford <robert.bradford@intel.com> |
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> |
8baa244e | 11-Nov-2020 |
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> |
46e73697 | 16-Nov-2020 |
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 ...
|
093a581e | 30-Oct-2020 |
Michael Zhao <michael.zhao@arm.com> |
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 ...
|
28e12e9f | 16-Oct-2020 |
Sebastien Boeuf <sebastien.boeuf@intel.com> |
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 ...
|
c4dc25de | 25-Sep-2020 |
Rob Bradford <robert.bradford@intel.com> |
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> |
573a5c63 | 08-Oct-2020 |
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 ...
|
ed1fdd1f | 07-Oct-2020 |
Wei Liu <liuwe@microsoft.com> |
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 ...
|
9ad14e6b | 07-Oct-2020 |
Wei Liu <liuwe@microsoft.com> |
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> |
71c435ce | 03-Sep-2020 |
Praveen Paladugu <prapal@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 ...
|
4b322520 | 24-Sep-2020 |
Praveen Paladugu <prapal@microsoft.com> |
hypervisor, vmm: fix clippy warnings
Signed-off-by: Praveen Paladugu <prapal@microsoft.com> |