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

[Don Slutz <dslutz@xxxxxxxxxxx>]

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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel