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). Jan
