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
next prev parent 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).