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

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

On 2/26/2016 5:50 PM, Paul Durrant wrote:
>> -----Original Message-----
>> From: Yu, Zhang [mailto:yu.c.zhang@linux.intel.com]
>> Sent: 26 February 2016 09:37
>> To: Jan Beulich
>> Cc: Paul Durrant; xen-devel@lists.xenproject.org
>> 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@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.
>
> 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@lists.xen.org
http://lists.xen.org/xen-devel