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

Re: [PATCH v3 1/2] x86/mm: rename FLUSH_FORCE_IPI to FLUSH_NO_ASSIST


  • To: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Wed, 25 May 2022 16:41:49 +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=Ayw2X1hAczj0AAK6zkbFFj87xksdKcNXGzvJn8aVHTo=; b=UcIzv9kHnG7hjM+nEhSvKxj7/8FqBQ4pJYHgFM/CKrDFceJIre3EMYvQiQeQndPeWHoXeZ4BoqyPuwcVKaOnbdx3TV/1b2OP0zegxzMIGA+sUB/epOc7nxlG1Cy+heUTsM7dDrF/X9N+hqnfeNuJuQ4pqYEQpelTw8QPB/3muv2V1ZEdf+wMyB6FHhta8R5hrl+AyAdqE6dAR6yhgo9yaLkYo1CQ12ne4GDIDKYomDX2RaPQqnZoetfjtvY7EBrjR0a86fI+C13iRY67uXo5mUnYqaj48N/tns8eCJMIbRNJ3sF5L7R66QCT7TdINfu62fAEI7FCeQrH+qCd1Sq1TQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gp6aZP5t6ge+mQdkW++RTddksijSPz7fh3EBx1ATOTwVW+IhLFf1o3lZCz65jvtvg1UzD7jfzJHHroTKW/HwoPnhwGe5vuDDQ1+Q+BcIUFWGoOvF/HIMwTkYmZcz0/fzHjJVdwJHbnrbZqhSZ+lXVbGgoYlHCGdYobZTfggPUBH4C8kp0XOvmF+P7ayNc+K/jpMLRfjRr/9s5AAUMLc0rOmG0buPKIS3c4MUXskLbU21cCKdABTYFFprG8W9lYrEmq26LvxK2OjomYt+biyER5CH7Turm1koJgzv3g4pSGDp5CZHSpQ0+OmicnDhNrU4x41n7TFgSHy7Vq9Ah7Bdag==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Wei Liu <wl@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Roger Pau Monne <roger.pau@xxxxxxxxxx>
  • Delivery-date: Wed, 25 May 2022 14:42:01 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 25.05.2022 16:33, Andrew Cooper wrote:
> On 25/05/2022 12:14, Jan Beulich wrote:
>> On 25.05.2022 12:52, Andrew Cooper wrote:
>>> On 25/05/2022 09:13, Roger Pau Monne wrote:
>>>> Rename the flag to better note that it's not actually forcing any IPIs
>>>> to be issued if none is required, but merely avoiding the usage of TLB
>>>> flush assistance (which itself can avoid the sending of IPIs to remote
>>>> processors).
>>>>
>>>> No functional change expected.
>>>>
>>>> Requested-by: Jan Beulich <jbeulich@xxxxxxxx>
>>>> Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
>>>> ---
>>>> Changes since v2:
>>>>  - New in this version.
>>> :(  This needs reverting.
>>>
>>> It is specific to IPIs, because of our current choice of algorithm for
>>> freeing pagetables.
>>>
>>> "no assist" excludes ipi-helper hypercalls which invoke
>>> INVALIDATE_TLB_VECTOR.  Such hypercalls do exist and specifically would
>>> be improvement that we ought to use.
>>>
>>> Furthermore, we do want to work around the limitation that created
>>> FLUSH_FORCE_IPI, because we absolutely do want to be able to use
>>> hypercalls/remote TLB flushing capabilities when available.
>>>
>>> I accept that FORCE_IPI perhaps isn't a perfect name, but it's a whole
>>> lot less bad than NO_ASSIST.
>> But FORCE_IPI has caused actual confusion while reviewing patch 2.
>> If NO_ASSIST doesn't suit you and FORCE_IPI is also wrong, can you
>> suggest a better name fitting both aspects?
> 
> I don't actually agree that FORCE_IPI is unclear to begin with.

You did see the earlier communication with Roger, didn't you? To
me the name pretty clearly suggests "always IPI" (hence "force"),
i.e. ...

> The safety property required is "if you need to contact a remote CPU, it
> must be by IPI to interlock with Xen's #PF handler".

... not in any way limited to remote CPUs. Yet patch 2 is about
cases where things are safe because no IPI will be needed (not
even a self-IPI).

> FORCE_IPI is very close to meaning this.  If anything else is unclear,
> it can be clarified in the adjacent comment.

I'm afraid I don't think a comment is what would help here.

Jan




 


Rackspace

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