From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47768) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xa8yU-0006uc-GX for qemu-devel@nongnu.org; Fri, 03 Oct 2014 15:57:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xa8yO-0007yE-In for qemu-devel@nongnu.org; Fri, 03 Oct 2014 15:57:10 -0400 Received: from fldsmtpe04.verizon.com ([140.108.26.143]:3774) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xa8yO-0007xv-Ds for qemu-devel@nongnu.org; Fri, 03 Oct 2014 15:57:04 -0400 From: Don Slutz Message-ID: <542EFF81.20407@terremark.com> Date: Fri, 03 Oct 2014 15:56:49 -0400 MIME-Version: 1.0 References: <1412274977-6098-1-git-send-email-dslutz@verizon.com> <1412274977-6098-2-git-send-email-dslutz@verizon.com> <9AAE0902D5BC7E449B7C8E4E778ABCD0110F4877@AMSPEX01CL01.citrite.net> In-Reply-To: <9AAE0902D5BC7E449B7C8E4E778ABCD0110F4877@AMSPEX01CL01.citrite.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Xen-devel] [RFC][PATCH v2 1/1] Add IOREQ_TYPE_VMWARE_PORT List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Durrant Cc: "Keir (Xen.org)" , Ian Campbell , Stefano Stabellini , "qemu-devel@nongnu.org" , Don Slutz , "xen-devel@lists.xen.org" , Jan Beulich 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 >> >>