From mboxrd@z Thu Jan 1 00:00:00 1970 From: Liran Alon Subject: Re: [PATCH 0/7] KVM: x86: Add support for VMware backdoor I/O ports & Pseduo-PMCs Date: Fri, 22 Dec 2017 03:22:26 +0200 Message-ID: <5A3C5E52.6070207@ORACLE.COM> References: <1513590316-4702-1-git-send-email-liran.alon@oracle.com> <6dfbcfce-e104-a2c3-b897-ba0bd634e24e@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: idan.brown@ORACLE.COM To: Paolo Bonzini , rkrcmar@redhat.com, kvm@vger.kernel.org Return-path: Received: from userp2120.oracle.com ([156.151.31.85]:39802 "EHLO userp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753761AbdLVBWc (ORCPT ); Thu, 21 Dec 2017 20:22:32 -0500 In-Reply-To: <6dfbcfce-e104-a2c3-b897-ba0bd634e24e@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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 >