> -----Original Message-----
> From: Jan Beulich <jbeul...@suse.com>
> Sent: 01 October 2020 15:42
> To: Don Slutz <don.sl...@gmail.com>
> Cc: xen-de...@lists.xen.org; Boris Ostrovsky <boris.ostrov...@oracle.com>;
> Ian Jackson
> <i...@xenproject.org>; Jun Nakajima <jun.nakaj...@intel.com>; Kevin Tian
> <kevin.t...@intel.com>;
> Stefano Stabellini <sstabell...@kernel.org>; Tim Deegan <t...@xen.org>;
> Andrew Cooper
> <andrew.coop...@citrix.com>; Konrad Rzeszutek Wilk <konrad.w...@oracle.com>;
> George Dunlap
> <george.dun...@eu.citrix.com>; Paul Durrant <p...@xen.org>
> Subject: Re: [XEN PATCH v14 7/8] Add IOREQ_TYPE_VMWARE_PORT
>
> On 19.08.2020 18:52, Don Slutz wrote:
> > This adds synchronization of the 6 vcpu registers (only 32bits of
> > them) that QEMU's vmport.c and vmmouse.c needs between Xen and QEMU.
> > This is how VMware defined the use of these registers.
> >
> > This is to avoid a 2nd and 3rd exchange between QEMU and Xen to
> > fetch and put these 6 vcpu registers used by the code in QEMU's
> > vmport.c and vmmouse.c
>
> I'm unconvinced this warrants a new ioreq type, and all the overhead
> associated with it. I'd be curious to know what Paul or the qemu
> folks think here.
>
The current shared ioreq_t does appear have enough space to accommodate 6
32-bit registers (in the addr, data, count and size) fields co couldn't the new
IOREQ_TYPE_VMWARE_PORT type be dealt with by simply unioning the regs with
these fields? That avoids the need for a whole new shared page.
Paul
