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

Re: [PATCH 1/2] x86: Perform mem_sharing teardown before paging teardown


  • To: Tamas K Lengyel <tamas@xxxxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Thu, 16 Feb 2023 15:26:57 +0100
  • 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=hjaZms3aw/Ub8Y3/Qm89xtSAbiAlHv+A21nsdu3cXV8=; b=FyP2QevatNxyGUSMMBc8q3E3ZkLUyMKouzLgj7N0qKvknSMsaFgqmLakKaXFhPqewSOeWdUm4RzfT/nFEhDBEqp3hHORf2Cty7y7K9XwEcl8HaNSmeC0BJpw4Q6jIHhKgNxKD4NAlgPuPiaG+NkfUrJLCl8N8nbK6zJwONr8occJBQdZDvfFF4VKLWxFN1kbQspaZZ5JmbszYgGKZicaxlccyJTAbMCfWxLyUbCPYtZXlDFdz/W3anW+waBvK7rxw/Bo7ahYtQ1Jp/ArVancqzsuDbpPfp4czhH6IPLzSor22LGDJPDSa1+6Dp915jSRWxUXvmJd2xe/LgyaKA9Guw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=N/v6FfiI/7FrdVXBAVsCHaajCCQOeT+O6o8FmZAU+DfhxcKzHkbiwCuShwnlhxrNb8p+OxtYeZfCbTJFmoVx2C/VJqbzRaZzj6riqZ25cCClW95oOb6z07dhxybX1LDpXcdXxDYBeToMyjymfvmKs3DRY2KH+6h4lEDk+WFNP2wOd12COWNSScM9C2d5yKQhRBTZiQG8XkuD+aXoag3TMUCnkU/JsHEboWqw3e/CWXhPJxFGqTBfjf6BOoTA725ixUe2mbXSb6KjWIrMFQzyo79FizHragqQowS090UatZ40jaYlUUzvSrlKAIE5M8nlB133QAPNADilRbQ3prTXtw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Thu, 16 Feb 2023 14:27:20 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 16.02.2023 13:22, Tamas K Lengyel wrote:
> On Thu, Feb 16, 2023 at 3:31 AM Jan Beulich <jbeulich@xxxxxxxx> wrote:
>>
>> On 15.02.2023 17:29, Tamas K Lengyel wrote:
>>> On Wed, Feb 15, 2023 at 5:27 AM Jan Beulich <jbeulich@xxxxxxxx> wrote:
>>>> Did you consider the alternative of adjusting the ASSERT() in question
>>>> instead? It could reasonably become
>>>>
>>>> #ifdef CONFIG_MEM_SHARING
>>>>     ASSERT(!p2m_is_hostp2m(p2m) || !remove_root ||
>>> !atomic_read(&d->shr_pages));
>>>> #endif
>>>>
>>>> now, I think. That would be less intrusive a change (helpful for
>>>> backporting), but there may be other (so far unnamed) benefits of
> pulling
>>>> ahead the shared memory teardown.
>>>
>>> I have a hard time understanding this proposed ASSERT.
>>
>> It accounts for the various ways p2m_teardown() can (now) be called,
>> limiting the actual check for no remaining shared pages to the last
>> of all these invocations (on the host p2m with remove_root=true).
>>
>> Maybe
>>
>>     /* Limit the check to the final invocation. */
>>     if ( p2m_is_hostp2m(p2m) && remove_root )
>>         ASSERT(!atomic_read(&d->shr_pages));
>>
>> would make this easier to follow? Another option might be to move
>> the assertion to paging_final_teardown(), ahead of that specific call
>> to p2m_teardown().
> 
> AFAICT d->shr_pages would still be more then 0 when this is called before
> sharing is torn down so the rearrangement is necessary even if we do this
> assert only on the final invocation. I did a printk in place of this assert
> without the rearrangement and afaict it was always != 0.

Was your printk() in an if() as above? paging_final_teardown() runs really
late during cleanup (when we're about to free struct domain), so I would
be somewhat concerned if by that time the count was still non-zero.

Jan



 


Rackspace

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