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

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

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

  Paul

> 
> B.R.
> Yu

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