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

[Paul Durrant <xadimgnik@xxxxxxxxx>]

> -----Original Message-----
> From: Jan Beulich <jbeulich@xxxxxxxx>
> Sent: 13 October 2020 10:38
> To: paul@xxxxxxx
> Cc: 'Don Slutz' <don.slutz@xxxxxxxxx>; 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>
> 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 <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).
> 

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