linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: EDAC on arm64
Date: Tue, 03 Mar 2015 10:23:06 +0100	[thread overview]
Message-ID: <2550695.nbkPi0RDF3@wuerfel> (raw)
In-Reply-To: <20150302222502.GA13277@MBP.local>

On Monday 02 March 2015 22:25:16 Catalin Marinas wrote:
> On Mon, Mar 02, 2015 at 08:40:16PM +0100, Arnd Bergmann wrote:
> > On Monday 02 March 2015 14:58:41 Catalin Marinas wrote:
> > > On Mon, Mar 02, 2015 at 10:59:32AM +0000, Will Deacon wrote:
> > > > On Sat, Feb 28, 2015 at 12:52:03AM +0000, Jon Masters wrote:
> > > > > Have you considered reviving the patch you posted previously for EDAC
> > > > > support (the atomic_scrub read/write test piece dependency)?
> > > > > 
> > > > > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-April/249039.html
> > > > 
> > > > Well, we'd need a way to handle the non-coherent DMA case and it's really
> > > > not clear how to fix that.
> > > 
> > > I agree, that's where the discussions stopped. Basically the EDAC memory
> > > writing is racy with any non-cacheable memory accesses (by CPU or
> > > device). The only way we could safely use this is only if all the
> > > devices are coherent *and* KVM is disabled. With KVM, guests may access
> > > the memory uncached, so we hit the same problem.
> > 
> > Is this a setting of the host, or does the guest always have this capability?
> 
> The guest can always make it stricter than what the host set in stage 2
> (i.e. from Normal Cacheable -> NonCacheable -> Device) but never in the
> other direction.

Do you have an idea what the purpose of this is? Why would a guest
even want to mark pages as noncachable that are mapped into the
host as cachable and that might have dirty cache lines?

> > If a guest can influence the caching of a page it has access to, I can
> > imagine all sorts of security problems with malicious guests regardless
> > of EDAC.
> 
> Not as long as the host is aware of this. Basically it needs to flush
> the cache on a page when it is mapped into the guest address space (IPA)
> and flush it again when reading a page from guest.

You have to flush and invalidate the cache line, but of course nobody
wants to do that because it totally destroys performance.

	Arnd

  reply	other threads:[~2015-03-03  9:23 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-28  0:52 EDAC on arm64 Jon Masters
2015-03-02 10:59 ` Will Deacon
2015-03-02 14:58   ` Catalin Marinas
2015-03-02 16:34     ` Rob Herring
2015-03-02 18:03       ` Catalin Marinas
2015-03-02 22:27       ` Catalin Marinas
2015-03-02 22:57         ` Rob Herring
2015-03-03 11:01           ` Catalin Marinas
2015-03-03 15:56             ` Rob Herring
2015-03-02 19:40     ` Arnd Bergmann
2015-03-02 22:25       ` Catalin Marinas
2015-03-03  9:23         ` Arnd Bergmann [this message]
2015-03-03 10:57           ` Catalin Marinas

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=2550695.nbkPi0RDF3@wuerfel \
    --to=arnd@arndb.de \
    --cc=linux-arm-kernel@lists.infradead.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).