From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH v9 06/13] xen: Add ring 3 vmware_port support Date: Tue, 17 Feb 2015 14:38:25 +0000 Message-ID: <54E35261.4010208@citrix.com> References: <1424127915-27004-1-git-send-email-dslutz@verizon.com> <1424127915-27004-7-git-send-email-dslutz@verizon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1424127915-27004-7-git-send-email-dslutz@verizon.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: 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 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? ~Andrew