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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 06.10.2020 10:13, Paul Durrant wrote:
> 
> 
>> -----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.

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