From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-kernel@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
stable@vger.kernel.org, David Vrabel <david.vrabel@citrix.com>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [ 13/13] x86/xen: do not identity map UNUSABLE regions in the machine E820
Date: Mon, 26 Aug 2013 18:08:45 -0700 [thread overview]
Message-ID: <20130827010310.845320600@linuxfoundation.org> (raw)
In-Reply-To: <20130827010309.850395966@linuxfoundation.org>
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Vrabel <david.vrabel@citrix.com>
commit 3bc38cbceb85881a8eb789ee1aa56678038b1909 upstream.
If there are UNUSABLE regions in the machine memory map, dom0 will
attempt to map them 1:1 which is not permitted by Xen and the kernel
will crash.
There isn't anything interesting in the UNUSABLE region that the dom0
kernel needs access to so we can avoid making the 1:1 mapping and
treat it as RAM.
We only do this for dom0, as that is where tboot case shows up.
A PV domU could have an UNUSABLE region in its pseudo-physical map
and would need to be handled in another patch.
This fixes a boot failure on hosts with tboot.
tboot marks a region in the e820 map as unusable and the dom0 kernel
would attempt to map this region and Xen does not permit unusable
regions to be mapped by guests.
(XEN) 0000000000000000 - 0000000000060000 (usable)
(XEN) 0000000000060000 - 0000000000068000 (reserved)
(XEN) 0000000000068000 - 000000000009e000 (usable)
(XEN) 0000000000100000 - 0000000000800000 (usable)
(XEN) 0000000000800000 - 0000000000972000 (unusable)
tboot marked this region as unusable.
(XEN) 0000000000972000 - 00000000cf200000 (usable)
(XEN) 00000000cf200000 - 00000000cf38f000 (reserved)
(XEN) 00000000cf38f000 - 00000000cf3ce000 (ACPI data)
(XEN) 00000000cf3ce000 - 00000000d0000000 (reserved)
(XEN) 00000000e0000000 - 00000000f0000000 (reserved)
(XEN) 00000000fe000000 - 0000000100000000 (reserved)
(XEN) 0000000100000000 - 0000000630000000 (usable)
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
[v1: Altered the patch and description with domU's with UNUSABLE regions]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/xen/setup.c | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -213,6 +213,17 @@ static void xen_align_and_add_e820_regio
e820_add_region(start, end - start, type);
}
+void xen_ignore_unusable(struct e820entry *list, size_t map_size)
+{
+ struct e820entry *entry;
+ unsigned int i;
+
+ for (i = 0, entry = list; i < map_size; i++, entry++) {
+ if (entry->type == E820_UNUSABLE)
+ entry->type = E820_RAM;
+ }
+}
+
/**
* machine_specific_memory_setup - Hook for machine specific memory setup.
**/
@@ -251,6 +262,17 @@ char * __init xen_memory_setup(void)
}
BUG_ON(rc);
+ /*
+ * Xen won't allow a 1:1 mapping to be created to UNUSABLE
+ * regions, so if we're using the machine memory map leave the
+ * region as RAM as it is in the pseudo-physical map.
+ *
+ * UNUSABLE regions in domUs are not handled and will need
+ * a patch in the future.
+ */
+ if (xen_initial_domain())
+ xen_ignore_unusable(map, memmap.nr_entries);
+
/* Make sure the Xen-supplied memory map is well-ordered. */
sanitize_e820_map(map, memmap.nr_entries, &memmap.nr_entries);
next prev parent reply other threads:[~2013-08-27 1:08 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-27 1:08 [ 00/13] 3.4.60-stable review Greg Kroah-Hartman
2013-08-27 1:08 ` [ 01/13] workqueue: fix possible stall on try_to_grab_pending() of a delayed work item Greg Kroah-Hartman
2013-08-27 1:08 ` [ 02/13] workqueue: consider work function when searching for busy work items Greg Kroah-Hartman
2013-08-27 1:08 ` [ 03/13] zd1201: do not use stack as URB transfer_buffer Greg Kroah-Hartman
2013-08-27 1:08 ` [ 04/13] xen/events: initialize local per-cpu mask for all possible events Greg Kroah-Hartman
2013-08-27 1:08 ` [ 05/13] drm/i915: Invalidate TLBs for the rings after a reset Greg Kroah-Hartman
2013-08-27 1:08 ` [ 06/13] of: fdt: fix memory initialization for expanded DT Greg Kroah-Hartman
2013-08-27 1:08 ` [ 07/13] nilfs2: remove double bio_put() in nilfs_end_bio_write() for BIO_EOPNOTSUPP error Greg Kroah-Hartman
2013-08-27 1:08 ` [ 08/13] nilfs2: fix issue with counting number of bio requests for BIO_EOPNOTSUPP error detection Greg Kroah-Hartman
2013-08-27 1:08 ` [ 09/13] Hostap: copying wrong data prism2_ioctl_giwaplist() Greg Kroah-Hartman
2013-08-27 1:08 ` [ 10/13] libata: apply behavioral quirks to sil3826 PMP Greg Kroah-Hartman
2013-08-27 1:08 ` [ 11/13] SCSI: zfcp: fix lock imbalance by reworking request queue locking Greg Kroah-Hartman
2013-08-27 1:08 ` [ 12/13] SCSI: zfcp: fix schedule-inside-lock in scsi_device list loops Greg Kroah-Hartman
2013-08-27 1:08 ` Greg Kroah-Hartman [this message]
2013-08-27 4:22 ` [ 00/13] 3.4.60-stable review Guenter Roeck
2013-08-27 22:31 ` Greg Kroah-Hartman
2013-08-27 20:42 ` Shuah Khan
2013-08-27 22:28 ` Greg Kroah-Hartman
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=20130827010310.845320600@linuxfoundation.org \
--to=gregkh@linuxfoundation.org \
--cc=david.vrabel@citrix.com \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@vger.kernel.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).