Re: [PATCH] docs/design: introduce HVMMEM_ioreq_serverX types

["Yu, Zhang" <yu.c.zhang@linux.intel.com>]

On 2/26/2016 5:18 PM, Jan Beulich wrote:
>>>> On 26.02.16 at 07:59, <yu.c.zhang@linux.intel.com> 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@lists.xen.org
http://lists.xen.org/xen-devel