[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: Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Date: Wed, 25 May 2022 16:40:00 +0200
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.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=//DGViIIewRqUuL+1svWGp0U9ClJsjRCLLvTMRLhMZ4=; b=gVpTuKGPlKegg3CBcoDbBBW/leYfKmynm019Czg458nOaJ5pvl5GvG3B9GuiCq++zTi1MXsv3y9bJozfaFpGC1SYFoeF3oUsl5BTpEoBjopUlPakELHqTeMh7mFA7rql0nMki7HGj51dPbkJiIpAFThvt23NzEU/wsglJofuv6ElaTPDF1A2aZ6a/QGW2NyM0an3fx9TiT9ENgoITqX49vYxzuucMca8xLPEe5Iu/I0cA/jDQ46xWQ/yf2prgsg2d01nBw2ed7GA+fBA1zXMImHh+GvOJGQ11THLI5zmSmqY7YQxDFCzKqaxdeHQdYEuL4Is6R02JbsJ32ZrYHZyLA==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FXgTY7h8AqkNpDQFRTOOUshVE0Ok5Jr0z7wOHIzB8XsO39sVTPfGZ1YTL5JOkZ/kH3igV7T7kpAeB80hBnmNr6nkZ1r8kxuxiMslGDldHPdgU/Khp0q7JXa6vLKTizpIxwY2X8RfArPUBYpn6wbUdsZAo2wu8ZAH0wCrud8ffL/daPxjrSxrTxOd60XfilaAVPrQEpZkx+mYNxIDfKTFYE1lQncghYXtpyU+NXOlghAue1l1Y5SQTvEMshS0oiFMSK8Ozi3LsJhfOqRaM980Jm3g6yUejpHxi26BJbFSfx8bRd4s7v/j4tfpZbEzW4YH9W5X8J3jQqxcnl7umnoBXw==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Wei Liu <wl@xxxxxxx>
- Delivery-date: Wed, 25 May 2022 14:40:18 +0000
- Ironport-data: A9a23:8j5WAarnlmo6iqJ3joVFyTgSaDheBmJsZBIvgKrLsJaIsI4StFCzt garIBmPa6yINGOmeosnPY7ipE9Tu8XXyNQyTFRkr30yRSkb+JuZCYyVIHmrMnLJJKUvbq7GA +byyDXkBJppJpMJjk71atANlVEliefQAOCU5NfsYkidfyc9IMsaoU8lyrdRbrJA24DjWVvQ4 46q+qUzBXf+s9JKGjNMg068gEsHUMTa4Fv0aXRnOJinFHeH/5UkJMp3yZOZdhMUcaENdgKOf M7RzanRw4/s10xF5uVJMFrMWhZirrb6ZWBig5fNMkSoqkAqSicais7XOBeAAKv+Zvrgc91Zk b1wWZKMpQgBDJKPsb9CaEdjLx4uOPIe37DNPWCGrpnGp6HGWyOEL/RGKmgTZNdd0MAnRGZE+ LofNSwHaQ2Fi6Su2rWnR+Jwh8Mlas72IIcYvXImxjbcZRokacmbH+OWupkFgXFp2Zwm8fX2P qL1bRJ1axvNeVtXM0o/A5Mihua4wHL4dlW0rXrK//NpuzmNk2Sd1pD1DIL7U8WWH/x1m2G7l 0PizyfTOFYjYYn3JT2ttyjEavX0tTP2XsceGaO18tZugUaP3SoDBRsOT1y5rPKlzEmkVLp3K UYZ5y4vpqga71GwQ5/2WBjQiGGAlg4RXZxXCeJS1e2W4q/d4gLcDG5USDdEMYYirJVvGmBs0 UKVldT0AzApqKeSVX+W6raTq3W1JDQRKmgBIyQDSGPp/uXenW36tTqXJv4LLUJ/poed9e3Yq 9xSkBUDug==
- Ironport-hdrordr: A9a23:7sH3zaEtCulqVWiEpLqFepHXdLJyesId70hD6qkvc3Fom52j/f xGws5x6faVslkssb8b6LW90Y27MAvhHPlOkPIs1NaZLXDbUQ6TQL2KgrGD/9SNIVycygcZ79 YbT0EcMqyOMbEZt7ec3ODQKb9Jrri6GeKT9IHjJh9WPH1XgspbnmNE42igYy9LrF4sP+tFKH PQ3LsPmxOQPVAsKuirDHgMWObO4/XNiZLdeBYDQzoq8hOHgz+E4KPzV0Hw5GZUbxp/hZMZtU TVmQ3w4auu99m91x/nzmfWq7BbgsHoxNdvDNGFzuIVNjLvoAC1Y5kJYczLgBkF5MWUrHo6mt jFpBkte+x19nPqZ2mw5SDg3gHxuQxen0PK+Bu9uz/OsMb5TDU1B45qnoRCaCbU7EImoZVVzL 9L93jxjesZMTrw2ADGo/TYXRBjkUS55VA4l/QIsnBZWYwCLJdMsI0k+l9PGptoJlO31GkeKp guMCjg3ocXTbvDBEqp/VWHgebcE0jbJy32DHTr4aeuonprdHMQ9Tps+CVQpAZEyHsHceg02w 31CNUXqFhwdL5nUUtcPpZ3fSLlMB26ffrzWFjiUmjPJeUgB0/njaLRzfEc2NyKEaZ4vqfa3q 6xGm9liQ==
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On Wed, May 25, 2022 at 10:52:48AM +0000, 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.
So the improvement of that mechanism is that you can pass a cpumask
parameter to an hypercall in order to avoid having to issue repeated
wrmsrs (or APIC MMIO accesses) to send IPIs to different vCPUs?
But that could be seen as generic assistance for triggering the
execution of remote IDT handlers, and as such won't be restricted by
the NO_ASSIST flag (also because it would be implemented in
send_IPI_mask() rather than flush_area_mask() IMO).
> 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 agree, we need to get rid of FLUSH_FORCE_IPI.
> I accept that FORCE_IPI perhaps isn't a perfect name, but it's a whole
> lot less bad than NO_ASSIST.
I'm happy for you and Jan to decide on a different name that you both
agree.
Thanks, Roger.
|
