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

[Don Slutz <dslutz@verizon.com>]

On 10/03/14 05:46, Paul Durrant wrote:
>> -----Original Message-----
>> From: Paul Durrant
>> Sent: 03 October 2014 10:29
>> To: 'Don Slutz'; xen-devel@lists.xen.org
>> Cc: Keir (Xen.org); Ian Campbell; Jan Beulich
>> Subject: RE: [Xen-devel] [RFC][PATCH v2 1/1] Add
>> IOREQ_TYPE_VMWARE_PORT
>>
>>> -----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
>>
...
>> Can we not avoid this overloading of the ioreq structure by having the
>> emulator directly modify the vCPU registers? Since the vCPU is paused for
>> emulation, could it not just do a get context/set context to tweak the values?
>>
> I should have added...
>
> Or if that doesn't work then surely an extra page of domheap, which can be mapped by the emulator to provide a dedicated channel, is preferable to this mechanism.

So for a 1 cpu guest adding a page (4096 bytes) to move 24 bytes of data 
is better
for this?

I would still add a new type.  And I would need a slot per cpu just like 
shared_iopage_t
of the same size or smaller (so it can stay 1 page).

I can prototype this out and see how big a change it would be.  It does 
have an impact
on QEMU so cc: qemu-devel


    -Don Slutz


>>    Paul
>>
>>