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

[Don Slutz <dslutz@xxxxxxxxxxx>]

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