Re: [Xen-devel] [PATCH] docs/design: introduce HVMMEM_ioreq_serverX types

["Yu, Zhang" <yu.c.zhang@xxxxxxxxxxxxxxx>]

On 2/26/2016 5:50 PM, Paul Durrant wrote:
> > -----Original Message-----
> > From: Yu, Zhang [mailto:yu.c.zhang@xxxxxxxxxxxxxxx]
> > Sent: 26 February 2016 09:37
> > To: Jan Beulich
> > Cc: Paul Durrant; xen-devel@xxxxxxxxxxxxxxxxxxxx
> > Subject: Re: [Xen-devel] [PATCH] docs/design: introduce
> > HVMMEM_ioreq_serverX types
> >
> > On 2/26/2016 5:18 PM, Jan Beulich wrote:
> > > > > > On 26.02.16 at 07:59, <yu.c.zhang@xxxxxxxxxxxxxxx> wrote:
> > > > > +Proposal
> > > > > +========
> > > > > +
> > > > > +Because the number of spare types available in the P2M type-space is
> > > > > +currently very limited it is proposed that
> > HVMMEM\_mmio\_write\_dm be
> > > > > +replaced by a single new type HVMMEM\_ioreq\_server. In future, if
> > the
> > > > > +P2M type-space is increased, this can be renamed to
> > HVMMEM\_ioreq\_server0
> > > > > +and new HVMMEM\_ioreq\_server1, HVMMEM\_ioreq\_server2, etc.
> > types
> > > > > +can be added.
> > > > > +
> > > > > +Accesses to a page of type HVMMEM\_ioreq\_serverX should be the
> > same as
> > > > > +HVMMEM\_ram\_rw until the type is _claimed_ by an IOREQ server.
> > Furthermore
> > > > Sorry, do you mean even when a gfn is set to HVMMEM_ioreq_serverX
> > type,
> > > > its access rights in P2M still remains unchanged? So the new hypercall
> > > > pair, HVMOP_[un]map_mem_type_to_ioreq_server, are also
> > responsible for
> > > > the PTE updates on the access bits?
> > > >
> > > > If it is true, I'm afraid this would be time consuming, because the
> > > > map/unmap will have to traverse all P2M structures to detect the PTEs
> > > > with HVMMEM_ioreq_serverX flag set. Yet in XenGT, setting this flag is
> > > > triggered dynamically with the construction/destruction of shadow
> > PPGTT.
> > > > But I'm not sure to which degree the performance casualties will be,
> > > > with frequent EPT table walk and EPT tlb flush.
> > > No walking of EPT trees will be necessary in that case, just like it
> > > already has been made unnecessary for other changes resulting
> > > in various PTE attributes needing re-calculation. We'll only need
> > > to extend the p2m_memory_type_changed() mechanism to cover
> > > changes like this one.
> > So you mean when the access bits are to be updated, we can leverage
> > something like p2m_memory_type_changed(which I guess only deals with
> > memory types, not access bits) to avoid the walking of EPT trees? I'll
> > need to study this part.
> No, the P2M is walked when the map/unmap hypercall is issued but, in the XenGT 
> use-case, that hypercall is issued once at start of day and - if everything is 
> working as it I believe it should - there won't actually be any pages of type 
> HVMMEM_ioreq_server at that point, so no EPT flush is required.
>
> > Anyway, thanks for your advice. :)
> I will post an implementation hopefully in the next few days once I've proved 
> it works in my XenGT rig.
Great. Looking forward to this implementation, and thanks for your
help. :)

B.R.
Yu


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel