[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:46, Paul Durrant wrote:
-----Original Message-----
From: Paul Durrant
Sent: 03 October 2014 10:29
To: 'Don Slutz'; xen-devel@xxxxxxxxxxxxx
Cc: Keir (Xen.org); Ian Campbell; Jan Beulich
Subject: RE: [Xen-devel] [RFC][PATCH v2 1/1] Add

-----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

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 

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


Xen-devel mailing list



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