[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [RFC][PATCH v2 1/1] Add IOREQ_TYPE_VMWARE_PORT



On 10/03/14 05:29, Paul Durrant wrote:
-----Original Message-----
From: xen-devel-bounces@xxxxxxxxxxxxx [mailto:xen-devel-
bounces@xxxxxxxxxxxxx] On Behalf Of Don Slutz
Sent: 02 October 2014 19:36
To: xen-devel@xxxxxxxxxxxxx
Cc: Don Slutz; Keir (Xen.org); Ian Campbell; Jan Beulich
Subject: [Xen-devel] [RFC][PATCH v2 1/1] Add IOREQ_TYPE_VMWARE_PORT

Signed-off-by: Don Slutz <dslutz@xxxxxxxxxxx>
---
v2:
     Fixup usage of hvmtrace_io_assist().
     VMware only changes the 32bit part of the register.
        Added vmware_ioreq_t

  xen/arch/x86/hvm/emulate.c        | 72
+++++++++++++++++++++++++++++++++++++++

...

+
+    ASSERT(sizeof(p) == sizeof(op));
+    ASSERT(offsetof(ioreq_t, type) == offsetof(vmware_ioreq_t, type));
+    ASSERT(offsetof(ioreq_t, vp_eport) == offsetof(vmware_ioreq_t,
vp_eport));
Can we not avoid this overloading of the ioreq structure by having the emulator 
directly modify the vCPU registers?

Yes we can at a high cost of cpu overhead.  The current ways of accessing
registers are mostly way too many registers and other side effects. Using
the debugger interface (which I do not know as well) has a high cost.


Since the vCPU is paused for emulation, could it not just do a get context/set 
context to tweak the values?

It is blocked not paused, and while I have not tried it, I would expect it to work. However it does require switching from qemu to the hypervisor and back 2 times
which is not free.

So I feel that adding a lot of overhead to avoid a new type ioreq_t is the wrong
way to go.

   -Don Slutz

   Paul




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.