[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 1/5] x86: support cache-writeback in flush_area_local() et al
- To: Jan Beulich <jbeulich@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
- Date: Wed, 19 Apr 2023 20:56:56 +0100
- 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=IiD3lT9jsNQl5Yegvqz5+XSeV3o+sEPBLk96esFJqL4=; b=CKnc9cClRlErsVxD3DMO8ySgQiipZ4Xi4f88kncnp+eHKKFEYTPUSR4Z+MIXQRjYZG3GlCV8A55A+QEj9hHtv2YK7JPoboDpmeTQqM3F3j9w5y97TCwnUe6yGP18GXngDmHl32VVugCdU2Cm9yJ/Bn8+e8ne3dfObxM9Infvi7pq9MJ6A7q6IvNFK8FZmh9h1qr3akUQkPggitZByccUSIBhWrCuL1a7WvHzpYHiUxHcf2fTB1RWJEMV8Fvs6YBzf1YG3gr7wNhpZHPBjxuAfDe8RZTSIgOEhXpO1T8h0dPrzvdfFUXwJlqJiSLmfMZknjjg9z6Gght6nbxMNKwjTA==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QtLoD7zo9ZX2HtuWp0qQwQzK+3b88phfVWfLlOWehsipq5gQZnWxiijxdugYTFEXudRtxG00ep5DmiJ7kl9NUAzW3Mo3JU0Yd5kVhCWIk+IHbsfQg3+zLkZqdNIqSnqkFl73lDKaAANgEVa+Z+WkLbJ1xyekU/5h+L+PNLucaCvKG14QfrQPR8bsqybg2qdxUlT4NQ4EwvpGEKiuIRSdDiLjStkdmlBwYTQzl8GoEKrm8X9qCS9HWaEKmgQHedYSTPkujSG05+s9mJnVo1p7OAY6G8PxvdWPjcMM4Q4CK5u55nFFvmAk1Em4P/HBjfzIE8mfw7aOfUoykZdXjpxFRA==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Delivery-date: Wed, 19 Apr 2023 19:57:22 +0000
- Ironport-data: A9a23:Bq3Ka6lm4O8CcbEzGDYYmFLo5gyjJ0RdPkR7XQ2eYbSJt1+Wr1Gzt xJOWD+DbPzZMTHwLd9xaNy18UoDvZ/Vy9EyTldprCk2HyMWpZLJC+rCIxarNUt+DCFhoGFPt JxCN4aafKjYaleG+39B55C49SEUOZmgH+a6U6icfHgqH2eIcQ954Tp7gek1n4V0ttawBgKJq LvartbWfVSowFaYCEpNg064gE4p7aWaVA8w5ARkPqgX5Q6GzRH5MbpETU2PByqgKmVrNrbSq 9brlNmR4m7f9hExPdKp+p6TnpoiG+O60aCm0xK6aoD66vRwjnVaPpUTbZLwXXx/mTSR9+2d/ f0W3XCGpaXFCYWX8AgVe0Ew/yiTpsSq8pefSZS0mZT7I0Er7xIAahihZa07FdRwxwp5PY1B3 ds7cy4XMTmAvuW32uLqR/Fvn90xPca+aevzulk4pd3YJdAPZMifBo/stZpf1jp2gd1SF/HDY cZfcSBocBnLfxxIPBEQFY46m+CrwHL4dlW0qnrM/fZxvzeVk1A3jOGF3Nn9I7RmQe18mEqCq 32A1GP+GhwAb/SUyCaf82LqjejK9c/+cNtKSuXkpq8w0DV/wEQ6CUJVfHegm8CmtReafvB9N XZFwiMH+P1aGEuDC4OVsweDiHyOswMYWtFQO/Yn8wzLwa3Riy6JC25BQjNfZdgOsM4tWSdsx lKPh8nuBzFkrPuSU3313qiQhSO/P24SN2BqWMMfZQ4M4t2mqodjiBvKFopnCPTt0oSzHizsy TeXqiR4n68UkcMAy6S8+xbAni6ooZ/KCAUy4207Q16Y0++wX6b9D6TA1LQRxa8owFqxJrVZg EU5pg==
- Ironport-hdrordr: A9a23:5nY2Eat2Cvs8md/WsvjXiaCN7skDU9V00zEX/kB9WHVpm62j9/ xG+c5x6faaslgssR0b6LW90cq7Lk80l6QV3WB5B97LNmSLhILPFvAa0WKL+UyGJ8TQzJ8+6U 4KSdkbNDSfNykBse/KpCW+DtY80J2m3cmT9JrjJzwEd3ANV0ga1XYbNu9DKDwPeOCRP+tDKK ah
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 19/04/2023 11:44 am, Jan Beulich wrote:
> --- a/xen/arch/x86/flushtlb.c
> +++ b/xen/arch/x86/flushtlb.c
> @@ -232,7 +232,7 @@ unsigned int flush_area_local(const void
> if ( flags & FLUSH_HVM_ASID_CORE )
> hvm_flush_guest_tlbs();
>
> - if ( flags & FLUSH_CACHE )
> + if ( flags & (FLUSH_CACHE | FLUSH_WRITEBACK) )
Given that we already have FLUSH_CACHE, then adding writeback also seems
fine, but we need to get the naming corrected first.
We've got a file called flushtlb.c which flushes more than the TLBs now,
and various APIs in it.
We have a bunch of ARM specific APIs which AFAICT exist purely to prop
up the ARM-specific gnttab_cache_flush(). That needs to go and live
behind an ifdef and stop polluting other architectures with an
incredibly short sighted hypercall interface decision.
The "area" in the low level calls isn't good. Range might be better,
but I'm not sure. The "mask" part of the name would be better as "some"
or perhaps "others", to be a better counterpoint to "local". Some of
the wrappers too really ought to be dropped - there are lots of them,
and too few users to justify.
But on to the main thing which caught my eye...
The FLUSH in FLUSH_CACHE means the flush infrastructure, not "cache
flushing", and FLUSH_WRITEBACK is nonsensical next to this. All other
things we flush have a qualification that makes them clear in context.
(other than the assist one which I'm going to time out objections to and
revert back to name which made more sense.)
At an absolutely minimum, FLUSH_CACHE first needs renaming to
FLUSH_CACHE_EVICT and then this new one you're adding needs to be
FLUSH_CACHE_WRITEBACK.
Except...
Is there any credible reason to have EVICT as an option by the end of
this cleanup?
CLDEMOTE does exist for a reason (reducing coherency traffic overhead
when you know the consumer is on a different CPU), but it would be
totally bogus to use this in an all or mask form, and you wouldn't want
to use it in local form either, simply from an overhead point of view.
We have evict behaviour simply because `clflush` was the only game in
town for decades, not because evicting the cacheline is what you want
actually want to do.
~Andrew
|