Re: [PATCH V4] xen/gnttab: Store frame GFN in struct page_info on Arm

[Oleksandr <olekstysh@gmail.com>]

On 14.12.21 18:45, Jan Beulich wrote:

Hi Jan.

> On 14.12.2021 17:26, Oleksandr wrote:
>> On 14.12.21 15:37, Jan Beulich wrote:
>>> On 03.12.2021 21:33, Oleksandr Tyshchenko wrote:
>>>> @@ -2177,14 +2181,22 @@ void *alloc_xenheap_pages(unsigned int order, unsigned int memflags)
>>>>    
>>>>    void free_xenheap_pages(void *v, unsigned int order)
>>>>    {
>>>> +    struct page_info *pg;
>>>> +    unsigned int i;
>>>> +
>>>>        ASSERT(!in_irq());
>>>>    
>>>>        if ( v == NULL )
>>>>            return;
>>>>    
>>>> +    pg = virt_to_page(v);
>>>> +
>>>>        memguard_guard_range(v, 1 << (order + PAGE_SHIFT));
>>> ... this really want to (logically) move into the new arch hooks.
>>> That'll effectively mean to simply drop the Arm stubs afaict (and I
>>> notice there's some dead code there on x86, which I guess I'll make
>>> a patch to clean up). But first of all this suggests that you want
>>> to call the hooks with base page and order, putting the loops there.
>> I see your point and agree ... However I see the on-list patches that
>> remove common memguard_* invocations and x86 bits.
>> So I assume, this request is not actual anymore, or I still need to pass
>> an order to new arch hooks? Please clarify.
> Well, that patch (really just the Arm one) effectively takes care of
> part of what I did say above. Irrespective I continue to think that
> the hook should take a (page,order) tuple instead of getting invoked
> once for every order-0 page. And the hook invocations should be placed
> such that they could fulfill the (being removed) memguard function
> (iirc that was already the case, at least mostly).

ok, thank you for the clarification, will do.


>
> Jan
>
-- 
Regards,

Oleksandr Tyshchenko