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

Re: [PATCH 6/9] xen/arm: introduce alloc_staticmem_pages and alloc_domstatic_pages


  • To: Julien Grall <julien@xxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 6 Jul 2021 11:59:24 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eltZ53WzeP6D32Cf1/FknSFJzekvUXZrLl6S5LDaCgM=; b=D9WsUrYgczfG7Cv5Lyv9d/cJhe7cYDHXByQAw0ML8Hr8/C/LVA+7lZIJpcwIVy0DXvxzbZRI729lyurskTRj2Ss/GQg+3t5q+9gxRDFYW8aXot88yDGkROhsS0baB+GE6OpbL9JToR6oEKoLgc3Zg/pAGCHxwJW08CJ0NZUEnq80sSHsgAs/CiR8OYltx4MzcIWucrjWyYz6fXz0KJDZbWKS2/JgKYGd3rC/bBghHOY/b+URrWdubhezGUxVSE5mbh5GQnkbEiZb0xB0gyxNseLyM1q3LquaXN4GTszpIh+IlPwimU1iTJ4H3+MCjCiQD2rovzWQTDP35+i11yXPgw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XAqVNqV6FnfnIjR/WkpjLWxTQ5JNoiMMWluXZP/4z1KZlrx4XTgdjutcff6AoBta6umLDCOJh4d21MR6lEQFaeDoiY7Ig0/Eg/q0jNszaHrxnW39QjyGxIPtPw1ojz9+dPNk1BoiSXm4BQVgFkF7umLtfRZGUio4Pyx+lBdMMDdPOrlXXW/NiGksyw5pS93JWn1mvfnE5bBbdObJJ1OOiPrlMFcZ2BkJ4grGY/fCywuCjd6F2NsGnCmN5bEpy1tPynLWIR7Cy3534UwcnKkFd2AAocKSyadoEKZaBx8seisiMMpp96FHSutvXV7fTa85YPeNbAXRzH/WvTYd6t6l0Q==
  • Authentication-results: arm.com; dkim=none (message not signed) header.d=none;arm.com; dmarc=none action=none header.from=suse.com;
  • Cc: Bertrand Marquis <Bertrand.Marquis@xxxxxxx>, Wei Chen <Wei.Chen@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, "sstabellini@xxxxxxxxxx" <sstabellini@xxxxxxxxxx>, Penny Zheng <Penny.Zheng@xxxxxxx>
  • Delivery-date: Tue, 06 Jul 2021 09:59:31 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 06.07.2021 11:39, Julien Grall wrote:
> Hi Jan & Penny,
> 
> On 06/07/2021 07:53, Jan Beulich wrote:
>> On 06.07.2021 07:58, Penny Zheng wrote:
>>>> From: Jan Beulich <jbeulich@xxxxxxxx>
>>>> Sent: Thursday, June 10, 2021 6:23 PM
>>>>
>>>> On 07.06.2021 04:43, Penny Zheng wrote:
>>>>> --- a/xen/common/page_alloc.c
>>>>> +++ b/xen/common/page_alloc.c
>>>>> @@ -1065,6 +1065,75 @@ static struct page_info *alloc_heap_pages(
>>>>>       return pg;
>>>>>   }
>>>>>
>>>>> +#ifdef CONFIG_STATIC_ALLOCATION
>>>>> +/*
>>>>> + * Allocate nr_mfns contiguous pages, starting at #smfn, of static 
>>>>> memory.
>>>>> + * It is the equivalent of alloc_heap_pages for static memory  */
>>>>> +static struct page_info *alloc_staticmem_pages(unsigned long nr_mfns,
>>>>> +                                               mfn_t smfn,
>>>>> +                                               unsigned int memflags)
>>>>> +{
>>>>> +    bool need_tlbflush = false;
>>>>> +    uint32_t tlbflush_timestamp = 0;
>>>>> +    unsigned long i;
>>>>> +    struct page_info *pg;
>>>>> +
>>>>> +    /* For now, it only supports allocating at specified address. */
>>>>> +    if ( !mfn_valid(smfn) || !nr_mfns )
>>>>> +    {
>>>>> +        printk(XENLOG_ERR
>>>>> +               "Invalid %lu static memory starting at %"PRI_mfn"\n",
>>>>
>>>> Reading a log containing e.g. "Invalid 0 static memory starting at ..." I 
>>>> don't
>>>> think I would recognize that the "0" is the count of pages.
>>>
>>> Sure. How about "try to allocate out of range page %"PRI_mfn"\n"?
>>
>> This still doesn't convey _both_ parts of the if() that would cause
>> the log message to be issued.
>>
>>>>> +               nr_mfns, mfn_x(smfn));
>>>>> +        return NULL;
>>>>> +    }
>>>>> +    pg = mfn_to_page(smfn);
>>>>> +
>>>>> +    for ( i = 0; i < nr_mfns; i++ )
>>>>> +    {
>>>>> +        /*
>>>>> +         * Reference count must continuously be zero for free pages
>>>>> +         * of static memory(PGC_reserved).
>>>>> +         */
>>>>> +        ASSERT(pg[i].count_info & PGC_reserved);
>>>>
>>>> What logic elsewhere guarantees that this will hold? ASSERT()s are to 
>>>> verify
>>>> that assumptions are met. But I don't think you can sensibly assume the 
>>>> caller
>>>> knows the range is reserved (and free), or else you could get away without 
>>>> any
>>>> allocation function.
>>>
>>> The caller shall only call alloc_staticmem_pages when it knows range is 
>>> reserved,
>>> like, alloc_staticmem_pages is only called in the context of 
>>> alloc_domstatic_pages
>>> for now.
>>
>> If the caller knows the static ranges, this isn't really "allocation".
>> I.e. I then question the need for "allocating" in the first place.
> 
> We still need to setup the page so the reference counting works 
> properly. So can you clarify whether you are objecting on the name? If 
> yes, do you have a better suggestion?

It's not the name alone but the disconnect between name and actual
behavior. Note that here we've started from an ASSERT(), which is
reasonable to have if the caller knows where static pages are, but
which should be converted to an if() when talking about allocation
(i.e. the caller may not have enough knowledge). If it's not really
allocation, how about naming it "acquire" or "obtain" (and the
config option perhaps STATIC_MEMORY)?

Jan




 


Rackspace

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