Re: [Xen-devel] Converting heap page_infos to contiguous virtual

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

On 07/13/2016 05:06 PM, Andrew Cooper wrote:
> On 13/07/2016 21:57, Boris Ostrovsky wrote:
>> On 07/13/2016 04:34 PM, Andrew Cooper wrote:
>>> On 13/07/2016 21:17, Boris Ostrovsky wrote:
>>>> On 07/13/2016 04:02 PM, Andrew Cooper wrote:
>>>>> On 13/07/16 20:44, Boris Ostrovsky wrote:
>>>>>> I would like to clear a bunch of Xen heap pages at once (i.e. not
>>>>>> page-by-page).
>>>>>>
>>>>>> Greatly simplifying things, let's say I grab (in common/page_alloc.c)
>>>>>>     pg = page_list_remove_head(&heap(node, zone, order)
>>>>>>
>>>>>> and then
>>>>>>
>>>>>>     mfn_t mfn =
>>>>>> _mfn(page_to_mfn(pg));                                        
>>>>>>     char *va = mfn_to_virt(mfn_x(mfn));
>>>>>>     memset(va, 0, 4096 * (1 << order));
>>>>>>
>>>>>>
>>>>>> Would it be valid to this?
>>>>> In principle, yes.  The frame_table is in order.
>>>>>
>>>>> However, mfn_to_virt() will blow up for RAM above the 5TB boundary.  You
>>>>> need to map_domain_page() to get a mapping.
>>>> Right, but that would mean going page-by-page, which I want to avoid.
>>>>
>>>> Now, DIRECTMAP_SIZE is ~128TB (if my math is correct) --- doesn't it
>>>> imply that it maps this big a range contiguously (modulo PDX hole)?
>>> Your maths is correct, and yet you will end up with problems if you
>>> trust it.
>>>
>>> That is the magic mode for the idle and monitor pagetables.  In the
>>> context of a 64bit PV guest, the cutoff is at 5TB, at which point you
>>> venture into the virtual address space reserved for guest kernel use. 
>>> (It is rather depressing that the 64bit PV guest ABI is the factor
>>> limiting Xen's maximum RAM usage.)
>> I don't know whether it would make any difference but the pages that I am
>> talking about are not in use by any guest, they are free. (This question
>> is for scrubbing rewrite that I am working on. Which apparently you
>> figured out judged by what you are saying below)
> Being free is not relevant.  It depends whether current is a 64bit PV
> guest or not.  Even in the idle loop, we don't context switch away from
> current's pagetables.


Can we force switch to idle (i.e. a non-64b PV guest) when we know
it would be useful for mapping/scrubbing? The cost of TLB flush (if that
was the reason) may be small compared to advantages brought by
fast mapping during scrubbing.


-boris


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