> -----Original Message----- > From: Jan Beulich <[email protected]> > Sent: 13 October 2020 10:38 > To: [email protected] > Cc: 'Don Slutz' <[email protected]>; [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]> > 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 <[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. > > 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
