Re: [RFC][PATCH v2 1/1] Add IOREQ_TYPE_VMWARE_PORT

[Don Slutz <dslutz@verizon.com>]

On 10/03/14 05:29, Paul Durrant wrote:
>> -----Original Message-----
>> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-
>> bounces@lists.xen.org] On Behalf Of Don Slutz
>> Sent: 02 October 2014 19:36
>> To: xen-devel@lists.xen.org
>> 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@verizon.com>
>> ---
>> 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
>
>