On 21/12/17 17:15, Paolo Bonzini wrote:
On 18/12/2017 10:45, Liran Alon wrote:
Hi,
This series aims to complete KVM support of VMware backdoor interface.
This interface is currently partially supported.
Before these commits, KVM forwaded accesses to vmport I/O ports to QEMU
where they were handled correctly.
However, it turns out VMware design allows these I/O ports to also be
accessible to guest when TSS I/O permissions bitmap disallows it.
The way VMware hypervisor does it is to intercept #GP and on #GP intercept
handler run the x86 emulator which was modified to specifically skip
checking TSS I/O permissions bitmap for these magic I/O ports.
This behavior was found to be a must for some VMware workloads.
For example, VMware Tools Windows installer refuse to install as it
cannot access vmport I/O ports from Ring3, therefore assuming it
is not running inside a VM.
Patches 1-6 mimics the above behavior in KVM. It installs a #GP
intercept on both VMX & SVM such that the #GP intercept handler
will call x86 emulator which was modified to always allow access
to these I/O ports.
Because this behavior is not a must for all workloads
and #GP intercept can introduce a slight performance overhead,
a module parameter was added to control whether KVM will do this or not.
Patch 7 finally completes VMware backdoor interface by adding support
for VMware Pseduo-PMCs. VMware defines a couple of PMCs which are made-up
by their hypervisor which returns various PV information
(Such as host's RDTSC). Similar to vmport I/O ports, these Pseduo-PMCs
can be accessed via RDPMC even if executed from Ring3 when CR4.PCE=0.
Therefore, the x86 emulator was modified to mimic this behavior.
Looks good, I have only a question in patch 3.
Replied on relevant discussion on patch 3.
Also, just for confirmation, in the nested case L1 can still trap #GP
using the exception bitmap, right? Can you write a testcase for
kvm-unit-tests/vmx.c, for both RDPMC and the 0x5658 port?
Yes.
vmx_handle_exit() makes sure to check if exit should be reflected to L1
before it runs L0 exit handler.
See how nested_vmx_exit_reflected() & nested_vmx_reflect_vmexit() are
called before one of the pointers at kvm_vmx_exit_handlers[].
handle_exception() is one of the handlers in kvm_vmx_exit_handlers[] and
therefore the handling of #GP intercept there should run only if the #GP
wasn't intercepted by L1.
In addition, in update_exception_bitmap() we make sure to not intercept
#GP if is_guest_mode(vcpu)==true. Because if we are running L2, L1
should be the one responsible for emulating #GP behaviour if any.
In addition, this is validated in handle_exception() #GP intercept
handler by a warning.
We have already written kvm-unit-tests for checking the functionality
introduced by this patch series that will be posted to upstream shortly.
I will find time to also add a test-case for vmx.c for the nested case.
Regards,
-Liran
Thanks,
Paolo
