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

Re: [PATCH v3 6/6] xen: retrieve reserved pages on populate_physmap


  • To: Penny Zheng <Penny.Zheng@xxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Thu, 5 May 2022 09:46:33 +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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=59XdpUfHVbilsEhtfR5JO0+5vwDqmAsmmdN1OvKCsKc=; b=Vx3hnxL5ZWB1fyKeyglyrI2cM78xPJXpNFhvmg57Gn6SIGWu2MCktBteKFasDfwfrJTC26H4zyFgrOG6JI/34qct0m8yOKIiNWuBT1mXy7RHt5Ui7P07LXZ3n7aH8gng6uJO6U6p08qF5pg6/dxh8PaPMySoRG1V69o6baxSLqYdshG1Qrd5upSMkqrETjMKHanQJu48nYgIOu6cMIz5W/Z8m9ehOPNV4yScS3Y/udvAz0TjOgWdIjpet+yH5erGXBukh+nT80IfL95GS93M5qore488rl+dZhfK9Jl5MY1qWDn/q5BaR6+B9X4SkVKGxwTYznaoDGFl2Y4d2eqbIQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lIwbPdvDXnVPnoBHj6k08AO8oR52B0pOrD4tELDaraa75/FCEBFPz7kPMy/9BVg60yk43uyOvNbam6qrTVKTSp+ulCRPdxgB/JqjAkU35k3sPx5vnw/3Tl/0f3sUzl9jb6Zo/hkTjxqAT3TWxtGonVHiyFpEeBYKv1Yp6JZeuJ/sSGFn7cWHV+kkU3NeX2t9T7w1ac3nX9efdD/3jBxuObfaF+0ydkSX95kqG2BTh0uw5RFNRl/rfJjsBJvyxYCRvxKf0UM0rlQwKqDNlvYCGL2BGiNbSpXZD/cjgyurKdEuLLIKlE0C4sEUv/AMEMlvulX+Jgypslc1mRQNPnUOsw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Wei Chen <Wei.Chen@xxxxxxx>, Henry Wang <Henry.Wang@xxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Thu, 05 May 2022 07:46:45 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 05.05.2022 08:24, Penny Zheng wrote:
>> From: Jan Beulich <jbeulich@xxxxxxxx>
>> Sent: Wednesday, May 4, 2022 9:45 PM
>>
>> On 27.04.2022 11:27, Penny Zheng wrote:
>>>  #else
>>>  void free_staticmem_pages(struct page_info *pg, unsigned long nr_mfns,
>>>                            bool need_scrub)  {
>>>      ASSERT_UNREACHABLE();
>>>  }
>>> +
>>> +int __init acquire_domstatic_pages(struct domain *d, mfn_t smfn,
>>> +                                   unsigned int nr_mfns, unsigned int
>>> +memflags) {
>>> +    ASSERT_UNREACHABLE();
>>> +}
>>
>> I can't spot a caller of this one outside of suitable #ifdef. Also the 
>> __init here
>> looks wrong and you look to have missed dropping it from the real function.
>>
>>> +mfn_t acquire_reserved_page(struct domain *d, unsigned int memflags)
>>> +{
>>> +    ASSERT_UNREACHABLE();
>>> +}
>>>  #endif
>>
>> For this one I'd again expect CSE to leave no callers, just like in the 
>> earlier
>> patch. Or am I overlooking anything?
>>
> 
> In acquire_reserved_page, I've use a few CONFIG_STATIC_MEMORY-only variables, 
> like
> d->resv_page_list, so I'd expect to let acquire_reserved_page guarded by 
> CONFIG_STATIC_MEMORY
> too and provide the stub function here to avoid compilation error when 
> !CONFIG_STATIC_MEMORY.

A compilation error should only result if there's no declaration of the
function. I didn't suggest to remove that. A missing definition would
only be noticed when linking, but CSE should result in no reference to
the function in the first place. Just like was suggested for the earlier
patch. And as opposed to the call site optimization the compiler can do,
with -ffunction-sections there's no way for the linker to eliminate the
dead stub function.

Jan




 


Rackspace

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