From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Cc: Keir Fraser <keir@xen.org>,
George Dunlap <george.dunlap@eu.citrix.com>,
Tim Deegan <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
Julien Grall <julien.grall@citrix.com>,
Stefano Stabellini <stefano.stabellini@citrix.com>,
Jan Beulich <JBeulich@suse.com>
Subject: [PATCH 0/4 v2] xen/arm: fix guest builder cache cohenrency (again, again)
Date: Tue, 4 Feb 2014 14:21:41 +0000 [thread overview]
Message-ID: <1391523701.5635.6.camel@kazak.uk.xensource.com> (raw)
Changes in v2:
Flush on page alloc and do targeted flushes at domain build time
rather than a big flush after domain build. This adds a new call
to common code, which is stubbed out on x86. This avoid needing
to worry about preemptability of the new domctl and also catches
cases related to ballooning where things might not be flushed
(e.g. a guest scrubs a page but doesn't clean the cache)
This has done 12000 boot loops on arm32 and 10000 on arm64.
Given the security aspect I would like to put this in 4.4.
Original blurb:
On ARM we need to take care of cache coherency for guests which we have
just built because they start with their caches disabled.
Our current strategy for dealing with this, which is to make guest
memory default to cacheable regardless of the in guest configuration
(the HCR.DC bit), is flawed because it doesn't handle guests which
enable their MMU before enabling their caches, which at least FreeBSD
does. (NB: Setting HCR.DC while the guest MMU is enabled is
UNPREDICTABLE, hence we must disable it when the guest turns its MMU
one).
There is also a security aspect here since the current strategy means
that a guest which enables its MMU before its caches can potentially see
unscrubbed data in RAM (because the scrubbed bytes are still held in the
cache).
As well as the new stuff this series removes the HCR.DC support and
performs two purely cosmetic renames.
Ian.
next reply other threads:[~2014-02-04 14:21 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-04 14:21 Ian Campbell [this message]
2014-02-04 14:22 ` [PATCH v2 1/4] xen: arm: rename create_p2m_entries to apply_p2m_changes Ian Campbell
2014-02-04 14:22 ` [PATCH v2 2/4] xen: arm: rename p2m next_gfn_to_relinquish to lowest_mapped_gfn Ian Campbell
2014-02-04 14:22 ` [PATCH v2 3/4] xen/arm: clean and invalidate all guest caches by VMID after domain build Ian Campbell
2014-02-04 15:00 ` Jan Beulich
2014-02-04 15:43 ` Ian Campbell
2014-02-04 15:48 ` Jan Beulich
2014-02-04 16:07 ` Ian Campbell
2014-02-04 16:42 ` Jan Beulich
2014-02-04 15:32 ` Ian Jackson
2014-02-04 15:37 ` Ian Campbell
2014-02-04 15:55 ` Ian Jackson
2014-02-04 16:09 ` Ian Campbell
2014-02-04 16:16 ` Ian Jackson
2014-02-04 14:22 ` [PATCH v2 4/4] Revert "xen: arm: force guest memory accesses to cacheable when MMU is disabled" Ian Campbell
2014-02-04 15:37 ` Julien Grall
2014-02-04 16:07 ` Ian Campbell
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=1391523701.5635.6.camel@kazak.uk.xensource.com \
--to=ian.campbell@citrix.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=JBeulich@suse.com \
--cc=george.dunlap@eu.citrix.com \
--cc=julien.grall@citrix.com \
--cc=keir@xen.org \
--cc=stefano.stabellini@citrix.com \
--cc=tim@xen.org \
--cc=xen-devel@lists.xen.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).