On 12/03/2018 12:12, 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. > > Changes from v2: > * Intercept #GP also in L2 in case VMware backdoor port is > passthrough from L1 to L2. > > Regards, > -Liran Alon > Looks good, thanks. I'm a bit tired so I'll test tomorrow. Paolo
