From mboxrd@z Thu Jan 1 00:00:00 1970 From: Don Slutz Subject: Re: [PATCH v9 06/13] xen: Add ring 3 vmware_port support Date: Wed, 18 Feb 2015 12:03:04 -0500 Message-ID: <54E4C5C8.6060003@terremark.com> References: <1424127915-27004-1-git-send-email-dslutz@verizon.com> <1424127915-27004-7-git-send-email-dslutz@verizon.com> <54E35261.4010208@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <54E35261.4010208@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andrew Cooper , Don Slutz , xen-devel@lists.xen.org Cc: Kevin Tian , Keir Fraser , Ian Campbell , Stefano Stabellini , Jun Nakajima , Eddie Dong , Ian Jackson , Tim Deegan , George Dunlap , Aravind Gopalakrishnan , Jan Beulich , Boris Ostrovsky , Suravee Suthikulpanit List-Id: xen-devel@lists.xenproject.org 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 >> --- >> 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 >> #include >> #include >> +#include >> >> 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 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 To: Don Slutz , Ian Campbell 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 (or all ports). -Don Slutz > ~Andrew >