xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Bertrand Marquis <Bertrand.Marquis@arm.com>
To: Julien Grall <julien@xen.org>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Julien Grall <jgrall@amazon.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Subject: Re: [PATCH for-next] xen/arm: mm: flush_page_to_ram() only need to clean to PoC
Date: Mon, 22 Feb 2021 13:48:58 +0000	[thread overview]
Message-ID: <7ADEDCE0-4C50-47B5-AA15-C5DF841FA330@arm.com> (raw)
In-Reply-To: <45cd6455-3ad0-f052-65d8-37adb658f003@xen.org>

Hi Julien,

> On 22 Feb 2021, at 13:37, Julien Grall <julien@xen.org> wrote:
> 
> 
> 
> On 22/02/2021 11:58, Bertrand Marquis wrote:
>> Hi Julien,
>>> On 20 Feb 2021, at 17:54, Julien Grall <julien@xen.org> wrote:
>>> 
>>> From: Julien Grall <jgrall@amazon.com>
>>> 
>>> At the moment, flush_page_to_ram() is both cleaning and invalidate to
>>> PoC the page. However, the cache line can be speculated and pull in the
>>> cache right after as it is part of the direct map.
>> If we go further through this logic maybe all calls to
>> clean_and_invalidate_dcache_va_range could be transformed in a
>> clean_dcache_va_range.
> 
> Likely yes. But I need to go through them one by one to confirm this is fine to do it (it also depends on the caching attributes used). I have sent this one in advance because this was discussed as part of XSA-364.

Ok.

> 
>>> 
>>> So it is pointless to try to invalidate the line in the data cache.
>>> 
>> But what about processors which would not speculate ?
>> Do you expect any performance optimization here ?
> 
> When invalidating a line, you effectively remove it from the cache. If the page is going to be access a bit after, then you will have to load from the memory (or another cache).
> 
> With this change, you would only need to re-fetch the line if it wasn't evicted by the time it is accessed.
> 
> The line would be clean, so I would expect the eviction to have less an impact over re-fetching the memory.

Make sense.

> 
>> If so it might be good to explain it as I am not quite sure I get it.
> 
> This change is less about performance and more about unnecessary work.
> 
> The processor is likely going to be more clever than the developper and the exact numbers will vary depending on how the processor decide to manage the cache.
> 
> In general, we should avoid interferring too much with the cache without a good reason to do it.
> 
> How about the following commit message:
> 
> "
> At the moment, flush_page_to_ram() is both cleaning and invalidate to
> PoC the page.
> 
> The goal of flush_page_to_ram() is to prevent corruption when the guest has disabled the cache (the cache line may be dirty) and read the guest to read previous content.
> 
> Per this defintion, the invalidating the line is not necessary. So invalidating the cache is unnecessary. In fact, it may be counter-productive as the line may be (speculatively) accessed a bit after. So this will incurr an expensive access to the memory.
> 
> More generally, we should avoid interferring too much with cache. Therefore, flush_page_to_ram() is updated to only clean to PoC the page.
> 
> The performance impact of this change will depend on your workload/processor.
> "
> 

With this as your commit message you can add my:

Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>

Thanks for details

Cheers
Bertrand

> -- 
> Julien Grall



  reply	other threads:[~2021-02-22 13:49 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-20 17:54 [PATCH for-next] xen/arm: mm: flush_page_to_ram() only need to clean to PoC Julien Grall
2021-02-22 11:58 ` Bertrand Marquis
2021-02-22 13:37   ` Julien Grall
2021-02-22 13:48     ` Bertrand Marquis [this message]
2021-02-22 20:35     ` Stefano Stabellini
2021-02-22 20:50       ` Julien Grall
2021-02-23  1:22         ` Stefano Stabellini
2021-03-03 18:33           ` Julien Grall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7ADEDCE0-4C50-47B5-AA15-C5DF841FA330@arm.com \
    --to=bertrand.marquis@arm.com \
    --cc=Volodymyr_Babchuk@epam.com \
    --cc=jgrall@amazon.com \
    --cc=julien@xen.org \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).