> -----Original Message-----
> From: Jan Beulich <[email protected]>
> Sent: 01 October 2020 15:42
> To: Don Slutz <[email protected]>
> Cc: [email protected]; Boris Ostrovsky <[email protected]>;
> Ian Jackson
> <[email protected]>; Jun Nakajima <[email protected]>; Kevin Tian
> <[email protected]>;
> Stefano Stabellini <[email protected]>; Tim Deegan <[email protected]>;
> Andrew Cooper
> <[email protected]>; Konrad Rzeszutek Wilk <[email protected]>;
> George Dunlap
> <[email protected]>; Paul Durrant <[email protected]>
> 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
