All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bill Burns <bburns@redhat.com>
To: xen-devel <xen-devel@lists.xensource.com>
Subject: RFC: large system support - 128 CPUs
Date: Tue, 12 Aug 2008 14:41:10 -0400	[thread overview]
Message-ID: <48A1D946.4040608@redhat.com> (raw)


There are a couple of issues with building the Hypervisor
with max_phys_cpus=128 for x86_64. (Note that this was
on a 3.1 base, but unstable appears to have
the same issue, at least with the first part).

First is a build assertion due to the size of
the page_info structure and the shadow_page_info
structures get out of sync due to the presence
of cpumask_t in the page info structure.

A possible fix is to tack on the following to
the end of shadow_page_info structure:

--- xen/arch/x86/mm/shadow/private.h.orig	2007-12-06 12:48:38.000000000 -0500
+++ xen/arch/x86/mm/shadow/private.h	2008-08-12 12:52:49.000000000 -0400
@@ -243,6 +243,12 @@ struct shadow_page_info
         /* For non-pinnable shadows, a higher entry that points at us */
         paddr_t up;
     };
+#if NR_CPUS > 64
+    /* Need to add some padding to match struct page_info size,
+    * if cpumask_t is larger than a long
+    */
+    u8 padding[sizeof(cpumask_t)-sizeof(long)];
+#endif
 };

 /* The structure above *must* be the same size as a struct page_info



The other issue is at runtime with a fault when
trying to bring up cpu 126. Seems the GDT space
reserved is not quite enough to hold the per
cpu entries. Crude fix (awaiting test results,
so not sure that this is sufficient.):

--- xen/include/asm-x86/desc.h.orig	2007-12-06 12:48:39.000000000 -0500
+++ xen/include/asm-x86/desc.h	2008-07-31 13:19:52.000000000 -0400
@@ -5,7 +5,11 @@
  * Xen reserves a memory page of GDT entries.
  * No guest GDT entries exist beyond the Xen reserved area.
  */
+#if MAX_PHYS_CPUS > 64
+#define NR_RESERVED_GDT_PAGES   2
+#else
 #define NR_RESERVED_GDT_PAGES   1
+#endif
 #define NR_RESERVED_GDT_BYTES   (NR_RESERVED_GDT_PAGES * PAGE_SIZE)
 #define NR_RESERVED_GDT_ENTRIES (NR_RESERVED_GDT_BYTES / 8)


Bill

             reply	other threads:[~2008-08-12 18:41 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-12 18:41 Bill Burns [this message]
2008-08-13  8:21 ` RFC: large system support - 128 CPUs Jan Beulich
2008-08-13  8:22   ` Tim Deegan
2008-08-13  8:26     ` Keir Fraser
2008-08-13  8:45       ` Jan Beulich
2008-08-13  8:47         ` Keir Fraser
2008-08-13  8:52           ` Keir Fraser
2008-08-13 10:23       ` Bill Burns
2008-08-13 10:25         ` Keir Fraser
2008-08-13 10:53           ` Bill Burns
2008-08-13 11:15             ` Keir Fraser
2008-08-13  8:21 ` Tim Deegan

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=48A1D946.4040608@redhat.com \
    --to=bburns@redhat.com \
    --cc=xen-devel@lists.xensource.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.