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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

Jan


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