[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 4/4] xen/arm: do not give memory back to static heap
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Luca Fancellu <Luca.Fancellu@xxxxxxx>
- Date: Tue, 26 Nov 2024 13:25:59 +0000
- Accept-language: en-GB, en-US
- Arc-authentication-results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com])
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
- Arc-message-signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=WF12mdFPRycqPo7kSem9k2ZQ7xAP9QoZLPj9I1A8qok=; b=vtTwppB8kw+FDJgS323WQ/Mfm34hdxRJRCj5qlaZ0YuP7Uihytsk4nV1hdqYfzF6r+gkNUUwmmeGkBR/sRFah8UiQFJQsum2KJ3wvf/psBYHSvHol+sFeOLBlfwc9tjMYFn9AONLq6IO7Mn1f04JeoRRq+EyyI3lByhbOQJo7542DBqmnpgr79u/2AbLzrKa11X9spaRNVYz0eOlVZvu8E4+yzX2brZeGQK3jvOoUC3NkMH2ICTf4iWz/6Am5ulOccdyjovc1YNZg/HJwQUrlUA3Yi9xWsWtMxMpU+diOPlBdOBkSngf0k6hRYSXkzgQBeWtueYEw8nqfdyHKZpMyw==
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=WF12mdFPRycqPo7kSem9k2ZQ7xAP9QoZLPj9I1A8qok=; b=FPXv7Y4hcmeQMOdW1JgoueNSlf3cFU/bpnb33cO8Gk0Oqd7Dom/XGQIKHTe24aagcVnvucovZZQiFfgCwjf6uGqwM9A9i20gm760O3qD6MTPi+G4DzzAMsJ/7pIL/Xi8j1Sgtr0XPxfS9FaFGSxtgzAJ8g4mohE7BkWpGvky4T6aLkaepYOV1xreIbkmeqYHKsxvFjttaxQJ+Ku+DBM8exiq5mges4JWuWBB6OWRUGYPkQYRb0mku5dmmeCXXQ658+hwGvVzE2kIcZ1h8+BspiBcEjiM/9w+AT+nPZwdyhqvb48I5jBSsgAlAt5yDQprMiuocs9kPtoP7ZZ4P0RRCA==
- Arc-seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=RKWYxGUrftUkAXrfOQvm0vANjSLhqA6ksQXKQF8VxoG++TH0s4BxabHlHgCgMcYtUsCW2vOHoxvrCq6h18lrkrpv8B0RniyJS583a7Zwvxr7feDbkAvfHfkXhS7QA5wYgJJOQloNMcS/p/HHR3Sul8/gmJ3JRuBWVc8J9ZTZS8F0+BcaSXEnrH8BA1vOeK8VJA9pJB3ThC7i4Ix9dXGkWJUW9CjPwdZmYwLyX5Rd1o2h37dFEJRY0PxqqBSRpWOEI3iMk36G4BHBRtFUdLDNo+cvx57ywpJro3k4H84vr5PUR0IP91gU+6VJ3SWCMMDBWMbOxya+OVoi6BAInwj6Pw==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Suqi0kYHXobYoiJLpadZ3+Rsn+dsldbq0xumXqOJK3eEH1ZUv0gHeXSabl7ei+Wk5oZ6UycbQfHBUI/ObOdkmrIr5M4WhH2UhVQ0NT3lBcVB7BJx3vX13uclWl1QfVBPfd6QasGOdUEqaO7ioYNj0pxPES9radWVbwbuWhXELT7pogpmtmpeLDm3ozXVYGq/7/A2RIJxN40XKaK1NnxHzE5nqPZkOTIlJUE0twLMjqmNO6ZzdM8YMtN5pIXHQWytCuWZkPIJ7HbObf0dmF/PAzd+svSySqBui4Hg/z7/FOvcP2JkPaOUkKQSdlOKassxsSg5akhaZ19i9ZP9bK7ogg==
- Authentication-results-original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
- Cc: Penny Zheng <Penny.Zheng@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Bertrand Marquis <Bertrand.Marquis@xxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Chen <Wei.Chen@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Tue, 26 Nov 2024 13:26:28 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
- Nodisclaimer: true
- Original-authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
- Thread-index: AQHbOmE/JeWd4mQRXU6E1FRNAbLoQLLIOm6AgAE0ZQCAAAS3gIAAJQWA
- Thread-topic: [PATCH v2 4/4] xen/arm: do not give memory back to static heap
Hi Jan,
>
> This reads better, thanks. Follow-on question: Is what is statically
> configured for the heap guaranteed to never overlap with anything passed
> to init_domheap_pages() in those places that you touch?
I think so, the places of the check are mainly memory regions related to boot
modules,
when we add a boot module we also do a check in order to see if it clashes with
any
reserved regions already defined, which the static heap is part of.
Could you explain me why the question?
>
>>>> --- a/xen/include/xen/bootfdt.h
>>>> +++ b/xen/include/xen/bootfdt.h
>>>> @@ -132,7 +132,6 @@ struct bootinfo {
>>>> #ifdef CONFIG_STATIC_SHM
>>>> struct shared_meminfo shmem;
>>>> #endif
>>>> - bool static_heap;
>>>> };
>>>>
>>>> #ifdef CONFIG_ACPI
>>>> @@ -157,6 +156,10 @@ struct bootinfo {
>>>>
>>>> extern struct bootinfo bootinfo;
>>>>
>>>> +#ifdef CONFIG_STATIC_MEMORY
>>>> +extern bool static_heap;
>>>> +#endif
>>>
>>> Just to double check Misra-wise: Is there a guarantee that this header will
>>> always be included by page-alloc.c, so that the definition of the symbol
>>> has an earlier declaration already visible? I ask because this header
>>> doesn't look like one where symbols defined in page-alloc.c would normally
>>> be declared. And I sincerely hope that this header isn't one of those that
>>> end up being included virtually everywhere.
>>
>> I’ve read again MISRA rule 8.4 and you are right, I should have included
>> bootfdt.h in
>> page-alloc.c in order to have the declaration visible before defining
>> static_heap.
>>
>> I will include the header in page-alloc.c
>
> Except that, as said, I don't think that header should be included in this
> file.
> Instead I think the declaration wants to move elsewhere.
Ok sorry, I misunderstood your comment, I thought you were suggesting to have
the
declaration visible in that file since we are defining there the variable.
So Julien suggested that file, it was hosted before in
common/device-tree/device-tree.c,
see the comment here:
https://patchwork.kernel.org/project/xen-devel/patch/20241115105036.218418-6-luca.fancellu@xxxxxxx/#26125054
Since it seems you disagree with Julien, could you suggest a more suitable
place?
Cheers,
Luca
|
