[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [RFC PATCH 71/84] x86/setup: start tearing down the direct map.



On 27.09.2019 16:02, hongyax@xxxxxxxxxx wrote:
> On 27/09/2019 14:00, Jan Beulich wrote:
>> On 27.09.2019 14:54, hongyax@xxxxxxxxxx wrote:
>>
>> Pre-populate? There's some conceptional question then: When the
>> direct map is gone, are you mapping Xen heap pages into the place
>> they'd have lived at in the direct map? I'm not convinced that's
>> what we want. In fact I'm not convinced we'd want to retain the
>> distinction between Xen heap and domain heap then any further -
>> there's no reason anymore at that point (afaict).
> 
> Yes. My patches map xenheap pages to where they would have lived on the 
> direct 
> map region, and unmap when xenheap pages are freed. The original proposal was 
> to use vmap() which we find difficult to implement.
> 
> - vmap takes an array of mfns. Mapping a large region require 
> allocating/freeing memory for a large array of mfns, unless we change or add 
> another vmap variant.
> - va<->pa conversion. Mapping xenheap to direct map region makes all the 
> xenheap conversion macros still work. The vmap proposal needs to add another 
> field in page_info (breaking the power of 2) or to have a separate structure 
> somewhere else for va/pa conversion.

But then why do the initial so many patches (inherited from Wei)
convert from domheap to xenheap allocations at all? If your
approach is to be at least an intermediate goal, then I think the
order of changes should be such that on-demand mapping of xenheap
pages occurs first, and then the xenheap -> domheap conversion
can happen in basically arbitrarily small steps.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.