|
From: | Don Slutz |
Subject: | Re: [Qemu-devel] [Xen-devel] [RFC][PATCH v2 1/1] Add IOREQ_TYPE_VMWARE_PORT |
Date: | Fri, 03 Oct 2014 15:56:49 -0400 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 |
On 10/03/14 05:46, Paul Durrant wrote:
-----Original Message----- From: Paul Durrant Sent: 03 October 2014 10:29 To: 'Don Slutz'; address@hidden 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: address@hidden [mailto:xen-devel- address@hidden On Behalf Of Don Slutz Sent: 02 October 2014 19:36 To: address@hidden Cc: Don Slutz; Keir (Xen.org); Ian Campbell; Jan Beulich Subject: [Xen-devel] [RFC][PATCH v2 1/1] AddIOREQ_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
[Prev in Thread] | Current Thread | [Next in Thread] |