[Xen-devel] Future x86 emulator direction

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

Hello,

I bring this query up now as I realise it will influence how I proceed
with the MSR and CPUID faulting improvements.

During the most recent Cambridge Hackathon (April 2016), there was a
suggestion made (sorry - I don't recall from whom) to feed the the
SVM/VMX intercept information into a slightly more general emulate
framework, rather than to try to implement common functionality in 3
separate locations.

I think this is a very good idea, but it does involve a quite
substantial change to the way things currently work; It would involve
making an emulation of an entire CPU, rather than just instructions.

For example, hvm_task_switch() currently works from the the intercept
hooks alone, but there is no support in the instruction emulator for
`lcall $TSS, $0`.  Inverting the current layout and having both the
intercepts and instruction emulator calling emulate->task_switch() would
fix this without needing to double up the task switch code.  Other
examples like this are VMMCALL/VMCALL, which should invoke the hypercall
path even if emulated.

On a different stance, we currently have multiple bits of code
implementing accessing/caching/updating of segment registers for hvm
guests.  With the introduction of the ->validate() hook, we should be
able to share all of this logic between the shadow and general emulation
paths, as it isn't use-dependent.

Overall, I think would cause a net reduction of logic living in
{svm,vmx}_vmexit_handler(), and a net simplification of other
emulator-related logic in the hypervisor.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel