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

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

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.
Anyway, thanks for your advice. :)

B.R.
Yu

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