Re: [PATCH 0/7] KVM: x86: Add support for VMware backdoor I/O ports & Pseduo-PMCs

[Liran Alon <LIRAN.ALON@ORACLE.COM>]

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
>