> -----Original Message----- > From: Jan Beulich <jbeul...@suse.com> > Sent: 13 October 2020 10:38 > To: p...@xen.org > Cc: 'Don Slutz' <don.sl...@gmail.com>; 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> > Subject: Re: [XEN PATCH v14 7/8] Add IOREQ_TYPE_VMWARE_PORT > > On 06.10.2020 10:13, Paul Durrant wrote: > > > > > >> -----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. > > Hmm, yes, good point. But this is assuming we're going to be fine with > using 32-bit registers now and going forward. Personally I'd prefer a > mechanism less constrained by the specific needs of the current VMware > interface, i.e. potentially allowing to scale to 64-bit registers as > well as any of the remaining 9 ones (leaving aside %rsp). >
I think that should probably be additional work, not needed for this series. We could look to expand and re-structure the ioreq_t structure with some headroom. An emulator aware of the new structure to resource map a different set of shared pages. Paul > Jan
