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

[Don Slutz <dslutz@xxxxxxxxxxx>]

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@xxxxxxxxxxx>
> > ---
> > 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@xxxxxxxxxx>
Date: Tue, 9 Sep 2014 15:22:30 -0400
From: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
        rv:24.0) Gecko/20100101 Thunderbird/24.2.0
To: Don Slutz <dslutz@xxxxxxxxxxx>, Ian Campbell <Ian.Campbell@xxxxxxxxxx>
References: <1409585629-25840-1-git-send-email-dslutz@xxxxxxxxxxx>		 
<1409585629-25840-4-git-send-email-dslutz@xxxxxxxxxxx>	 
<1410183310.3680.28.camel@xxxxxxxxxxxxxxxxxxxxxx>	 
<540DDFFB.2090504@xxxxxxxxxxxxx> 
<1410255363.8217.62.camel@xxxxxxxxxxxxxxxxxxxxxx>
        <540F3967.5060001@xxxxxxxxxxxxx>
In-Reply-To: <540F3967.5060001@xxxxxxxxxxxxx>

...

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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel