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 <dsl...@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.6020...@oracle.com>
Date: Tue, 9 Sep 2014 15:22:30 -0400
From: Boris Ostrovsky <boris.ostrov...@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:24.0) Gecko/20100101 Thunderbird/24.2.0
To: Don Slutz <dsl...@verizon.com>, Ian Campbell <ian.campb...@citrix.com>
References: <1409585629-25840-1-git-send-email-dsl...@verizon.com>
<1409585629-25840-4-git-send-email-dsl...@verizon.com>
<1410183310.3680.28.ca...@kazak.uk.xensource.com>
<540ddffb.2090...@terremark.com>
<1410255363.8217.62.ca...@kazak.uk.xensource.com>
<540f3967.5060...@terremark.com>
In-Reply-To: <540f3967.5060...@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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
