RE: [XEN PATCH v14 7/8] Add IOREQ_TYPE_VMWARE_PORT

[Paul Durrant <xadimgnik@xxxxxxxxx>]

> -----Original Message-----
> From: Jan Beulich <jbeulich@xxxxxxxx>
> Sent: 01 October 2020 15:42
> To: Don Slutz <don.slutz@xxxxxxxxx>
> Cc: xen-devel@xxxxxxxxxxxxx; Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>; 
> Ian Jackson
> <iwj@xxxxxxxxxxxxxx>; Jun Nakajima <jun.nakajima@xxxxxxxxx>; Kevin Tian 
> <kevin.tian@xxxxxxxxx>;
> Stefano Stabellini <sstabellini@xxxxxxxxxx>; Tim Deegan <tim@xxxxxxx>; Andrew 
> Cooper
> <andrew.cooper3@xxxxxxxxxx>; Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>; 
> George Dunlap
> <George.Dunlap@xxxxxxxxxxxxx>; Paul Durrant <paul@xxxxxxx>
> 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