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

Re: [PATCH 4/9] xen/arm: static memory initialization


  • To: Penny Zheng <Penny.Zheng@xxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Mon, 5 Jul 2021 09:48: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=379muhCbVU28mtoZW/NN4A3h4S25XYXXLW+AQ/yDtGY=; b=iOY/Lv7Oj/9fFGgY7WSJhqlpx6c9e4xgAoHzDaiiOPuOz3EHtk1kKVbBinxe3ctd/ceDsvyOCZp0mp71fZLaF5XxBieWXk38LaOpQPtNWhvc1bL51wNzQc1PLuXarnvYrdrVBEP2DyXDsDwHd8SVinKK9KpXCtRq0QS9i3Wuy6H26wO2UGJUVozu0S6MN7gWYXBQkj1AASOkkLkHSxm867C4bQzuZQA4iFEnIu558eVN9yMFxklGMr2Qmrj/kcuLJOHQC58fJeHeTcdQY+H3CsJZoKS0lGIsNrlb5LRgWI1Qwr1OFXxGatEMrtM3XqHYFPwj01lhTlSRJpEF5J4SWQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=U1oW4cccrSM7ihy0ffe9bulXVCPr/QHMVtZwOpRN3XQF8SGLAIsFobSXOHmH++i7N5/t+RmR2UT/J7c/V/V5kp0Q0HwJUj1MlHImY3EIUgJimfhOw3SiyK+6M47uQPJcT2d1w6qb9DpLIqXZuRWhHt7VbUirDpvvBcLo8OPXP0TeGxrEvWnkyrkLBCA0A9KrwN8wX5o1ol/+NuwzeDidBopKfSWpTjpmoXRSc6tvZOTcL+FZIPvSFMyPbIR9uZ+8GwOzAh/5QMD0QxXbUKM4IU4tLyimeNSOHdLnjKIOXGvFP5Gfb+idfctSnI3shr6k2mzrYoxtejvcE9oNTOLbZQ==
  • Authentication-results: xen.org; dkim=none (message not signed) header.d=none;xen.org; 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>, Julien Grall <julien@xxxxxxx>
  • Delivery-date: Mon, 05 Jul 2021 07:48:50 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 05.07.2021 07:22, Penny Zheng wrote:
>> From: Julien Grall <julien@xxxxxxx>
>> Sent: Thursday, July 1, 2021 1:46 AM
>>
>> On 10/06/2021 10:35, Jan Beulich wrote:
>>> On 07.06.2021 04:43, Penny Zheng wrote:
>>>> @@ -1512,6 +1530,38 @@ static void free_heap_pages(
>>>>       spin_unlock(&heap_lock);
>>>>   }
>>>>
>>>> +#ifdef CONFIG_STATIC_ALLOCATION
>>>> +/* Equivalent of free_heap_pages to free nr_mfns pages of static
>>>> +memory. */ void __init free_staticmem_pages(struct page_info *pg,
>> unsigned long nr_mfns,
>>>> +                                 bool need_scrub) {
>>>> +    mfn_t mfn = page_to_mfn(pg);
>>>> +    unsigned long i;
>>>> +
>>>> +    for ( i = 0; i < nr_mfns; i++ )
>>>> +    {
>>>> +        switch ( pg[i].count_info & PGC_state )
>>>> +        {
>>>> +        case PGC_state_inuse:
>>>> +            BUG_ON(pg[i].count_info & PGC_broken);
>>>> +            /* Mark it free and reserved. */
>>>> +            pg[i].count_info = PGC_state_free | PGC_reserved;
>>>> +            break;
>>>> +
>>>> +        default:
>>>> +            printk(XENLOG_ERR
>>>> +                   "Page state shall be only in PGC_state_inuse. "
>>>
>>> Why? A page (static or not) can become broken while in use. IOW I
>>> don't think you can avoid handling PGC_state_offlining here. At which
>>> point this code will match free_heap_pages()'es, and hence likely will
>>> want folding as well.
>>>
> 
> Yeah, I was following the logic in free_heap_pages.
> Hmmm, I could not think of any scenario that will lead to 
> PGC_state_offlining, that's why
> I was not including it at the first place.
> For broken issue, tbh, I just copy the bug_on from free_heap_pages, after 
> quite a time thinking,
> I also could not find any scenario when a page(static or not) can become 
> broken while in use. ;/

I can see that what you say may be true for Arm, but we're in generic
code here with an arch-independent CONFIG_STATIC_ALLOCATION conditional
around. Hence you want to avoid deliberately not handling a case that
can occur on e.g. x86 (see mark_page_offline() and further related
handling elsewhere). I'd perhaps view this differently if you were
introducing completely new code, but you've specifically said you're
cloning existing code (where the case is being handled). Plus, as said,
you'll likely be able to actually share code by not excluding the case
here.

Jan




 


Rackspace

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