From: Julien Grall <julien@xen.org>
To: Jan Beulich <jbeulich@suse.com>
Cc: Bertrand Marquis <Bertrand.Marquis@arm.com>,
Wei Chen <Wei.Chen@arm.com>,
"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
"sstabellini@kernel.org" <sstabellini@kernel.org>,
Penny Zheng <Penny.Zheng@arm.com>
Subject: Re: [PATCH 6/9] xen/arm: introduce alloc_staticmem_pages and alloc_domstatic_pages
Date: Tue, 6 Jul 2021 11:31:44 +0100 [thread overview]
Message-ID: <564b9851-4e3a-b98d-08a8-483c9ed83bb4@xen.org> (raw)
In-Reply-To: <ea219d56-ea73-8904-ab47-421bd5c53a9f@suse.com>
Hi,
On 06/07/2021 10:59, Jan Beulich wrote:
> 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@suse.com>
>>>>> 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)?
The caller will fetch the information from the Device Tree but it
doesn't sanity check it. I think it can be easy to make mistake as the
information will be scattered in various node of the DT.
So I think it would be better if we have a check in both prod and debug
build to ease the integration.
Regarding the name itself, anyone of the one you suggested are fine with
me because to me the difference between them is too subtle to be
understood by most of the users.
Cheers,
--
Julien Grall
next prev parent reply other threads:[~2021-07-06 10:31 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-07 2:43 [PATCH V2 0/9] Domain on Static Allocation Penny Zheng
2021-06-07 2:43 ` [PATCH 1/9] xen/arm: introduce domain " Penny Zheng
2021-06-07 2:43 ` [PATCH 2/9] xen/arm: introduce PGC_reserved Penny Zheng
2021-06-30 17:44 ` Julien Grall
2021-07-05 3:09 ` Penny Zheng
2021-06-07 2:43 ` [PATCH 3/9] xen/arm: introduce CONFIG_STATIC_ALLOCATION Penny Zheng
2021-06-07 6:17 ` Jan Beulich
2021-06-30 17:45 ` Julien Grall
2021-07-05 3:16 ` Penny Zheng
2021-06-07 2:43 ` [PATCH 4/9] xen/arm: static memory initialization Penny Zheng
2021-06-10 9:35 ` Jan Beulich
2021-06-30 17:46 ` Julien Grall
2021-07-05 5:22 ` Penny Zheng
2021-07-05 7:14 ` Penny Zheng
2021-07-05 7:50 ` Jan Beulich
2021-07-05 9:19 ` Penny Zheng
2021-07-05 7:48 ` Jan Beulich
2021-06-30 18:09 ` Julien Grall
2021-07-05 7:28 ` Penny Zheng
2021-07-06 9:09 ` Julien Grall
2021-07-06 9:20 ` Penny Zheng
2021-07-06 9:26 ` Julien Grall
2021-06-07 2:43 ` [PATCH 5/9] xen: introduce assign_pages_nr Penny Zheng
2021-06-10 9:49 ` Jan Beulich
2021-06-30 18:29 ` Julien Grall
2021-07-01 8:26 ` Jan Beulich
2021-07-01 9:24 ` Julien Grall
2021-07-01 10:13 ` Jan Beulich
2021-06-07 2:43 ` [PATCH 6/9] xen/arm: introduce alloc_staticmem_pages and alloc_domstatic_pages Penny Zheng
2021-06-10 10:23 ` Jan Beulich
2021-07-06 5:58 ` Penny Zheng
2021-07-06 6:53 ` Jan Beulich
2021-07-06 9:39 ` Julien Grall
2021-07-06 9:59 ` Jan Beulich
2021-07-06 10:31 ` Julien Grall [this message]
2021-07-08 9:09 ` Penny Zheng
2021-07-08 10:06 ` Jan Beulich
2021-07-08 11:07 ` Penny Zheng
2021-06-07 2:43 ` [PATCH 7/9] xen/arm: take care of concurrency on static memory allocation Penny Zheng
2021-06-10 10:53 ` Jan Beulich
2021-06-07 2:43 ` [PATCH 8/9] xen/arm: check `xen,static-mem` property during domain construction Penny Zheng
2021-07-03 13:26 ` Julien Grall
2021-07-06 6:31 ` Penny Zheng
2021-07-06 6:57 ` Jan Beulich
2021-07-06 7:35 ` Penny Zheng
2021-07-06 9:22 ` Julien Grall
2021-06-07 2:43 ` [PATCH 9/9] xen/arm: introduce allocate_static_memory Penny Zheng
2021-07-03 14:18 ` Julien Grall
2021-07-06 7:30 ` Penny Zheng
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=564b9851-4e3a-b98d-08a8-483c9ed83bb4@xen.org \
--to=julien@xen.org \
--cc=Bertrand.Marquis@arm.com \
--cc=Penny.Zheng@arm.com \
--cc=Wei.Chen@arm.com \
--cc=jbeulich@suse.com \
--cc=sstabellini@kernel.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.