Re: [PATCH v9 06/13] xen: Add ring 3 vmware_port support

[Don Slutz <dslutz@verizon.com>]

On 02/17/15 09:38, Andrew Cooper wrote:
> On 16/02/15 23:05, Don Slutz wrote:
>> Summary is that VMware treats "in (%dx),%eax" (or "out %eax,(%dx)")
>> to port 0x5658 specially.  Note: since many operations return data
>> in EAX, "in (%dx),%eax" is the one to use.  The other lengths like
>> "in (%dx),%al" will still do things, only AL part of EAX will be
>> changed.  For "out %eax,(%dx)" of all lengths, EAX will remain
>> unchanged.
>>
>> This instruction is allowed to be used from ring 3.  To
>> support this the vmexit for GP needs to be enabled.  I have not
>> fully tested that nested HVM is doing the right thing for this.
>>
>> The support included is enough to allow VMware tools to install in a
>> HVM domU.
>>
>> Enable no-fault of pio in x86_emulate for VMware port
>>
>> Also adjust the emulation registers after doing a VMware
>> backdoor operation.
>>
>> Add new routine hvm_emulate_one_gp() to be used by the #GP fault
>> handler.
>>
>> Some of the best info is at:
>>
>> https://sites.google.com/site/chitchatvmback/backdoor
>>
>> Signed-off-by: Don Slutz <dslutz@verizon.com>
>> ---
>> v9:
>>    Split #GP handling (or skipping of #GP) code out of previous
>>    patch to help with the review process.
>>    Switch to x86_emulator to handle #GP
>>    I think the hvm_emulate_ops_gp() covers all needed ops.  Not able to validate
>>    all paths though _hvm_emulate_one().
>>
>>  xen/arch/x86/hvm/emulate.c             | 62 ++++++++++++++++++++++++++++++++--
>>  xen/arch/x86/hvm/svm/svm.c             | 27 +++++++++++++++
>>  xen/arch/x86/hvm/svm/vmcb.c            |  2 ++
>>  xen/arch/x86/hvm/vmware/vmport.c       | 11 ++++++
>>  xen/arch/x86/hvm/vmx/vmcs.c            |  2 ++
>>  xen/arch/x86/hvm/vmx/vmx.c             | 38 +++++++++++++++++++++
>>  xen/arch/x86/x86_emulate/x86_emulate.c | 25 +++++++++++---
>>  xen/arch/x86/x86_emulate/x86_emulate.h |  8 +++++
>>  xen/include/asm-x86/hvm/emulate.h      |  2 ++
>>  xen/include/asm-x86/hvm/vmport.h       |  1 +
>>  10 files changed, 172 insertions(+), 6 deletions(-)
>>
>> diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
>> index 636c909..a6a6a5c 100644
>> --- a/xen/arch/x86/hvm/emulate.c
>> +++ b/xen/arch/x86/hvm/emulate.c
>> @@ -22,6 +22,7 @@
>>  #include <asm/hvm/trace.h>
>>  #include <asm/hvm/support.h>
>>  #include <asm/hvm/svm/svm.h>
>> +#include <asm/hvm/vmport.h>
>>
>>  static void hvmtrace_io_assist(int is_mmio, ioreq_t *p)
>>  {
>> @@ -776,6 +777,7 @@ static int hvmemul_read_io_discard(
>>      unsigned long *val,
>>      struct x86_emulate_ctxt *ctxt)
>>  {
>> +    ctxt->do_vmport = 0;
>
> This looks horribly invasive.
>
> Why are emulation changes needed?  What is wrong with the normal
> handling with a registered ioport handler?

Because VMware made a bad way to provide a "hyper call".  They decided to
allow user access to this.  So when a #GP fault should have been 
reported, they instead do the "hyper call".


 From older thread:

Message-ID: <540F5376.6020803@oracle.com>
Date: Tue, 9 Sep 2014 15:22:30 -0400
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
To: Don Slutz <dslutz@verizon.com>, Ian Campbell <Ian.Campbell@citrix.com>
References: <1409585629-25840-1-git-send-email-dslutz@verizon.com>		 
<1409585629-25840-4-git-send-email-dslutz@verizon.com>	 
<1410183310.3680.28.camel@kazak.uk.xensource.com>	 
<540DDFFB.2090504@terremark.com> 
<1410255363.8217.62.camel@kazak.uk.xensource.com>
	<540F3967.5060001@terremark.com>
In-Reply-To: <540F3967.5060001@terremark.com>

...

On 09/09/2014 01:31 PM, Don Slutz wrote:
 > On 09/09/14 05:36, Ian Campbell wrote:
 >> On Mon, 2014-09-08 at 12:57 -0400, Don Slutz wrote:
 >>>>> Also this instruction is allowed to be used from ring 3.  To
 >>>>> support this the vmexit for GP needs to be enabled.
 >>>> Isn't that quite costly?
 >>> Yes.  But since that is how VMware does it, I need to do the same slow
 >>> thing.
 >> Sounds from other subthreads like there might be other better ways? It's
 >> hard to believe that vmware is really trapping every #GP.
 >
 > I have not found a better way.  The simplest statement I have come
 > up with is that this is not a pass thru of the VMware device.  Or the
 > statement (in AMD land): Generate an IOIO #VMEXIT not a GP
 > #VMWEXIT for ioport <x> (or all ports).


    -Don Slutz


> ~Andrew
>