From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Rusty Russell <rusty@rustcorp.com.au>,
Chris Wright <chrisw@sous-sol.org>,
Zachary Amsden <zach@vmware.com>
Cc: Virtualization Mailing List <virtualization@lists.osdl.org>
Subject: pv_ops smp support
Date: Thu, 19 Oct 2006 16:09:51 -0700 [thread overview]
Message-ID: <453805BF.80301@goop.org> (raw)
I'm looking at adding Xen SMP support, so I'm trying to work out what
pv_ops we need, and how to cut into the existing smp stuff.
smpboot.c has a mixture of stuff which is generally useful for SMP stuff
(the various CPU sets, and presumably the sibling relationships are
useful in principle), but also a whole pile of APIC stuff which is
irrelevent to Xen. It has these exported symbols, with my first pass
comments:
00000644 T __cpu_die -- need pv_op
000008a5 T __cpu_disable -- need pv_op
000006aa T __cpu_up -- need pv_op
00000000 T cpu_coregroup_map -- ? ignore
00000868 T cpu_exit_clear -- ?
00000d9f T initialize_secondary -- Xen no-op
000008ee T smp_alloc_memory -- Xen no-op (doesn't matter if it gets called)
00000057 T smp_cpus_done -- unwanted for Xen
00000015 T smp_intr_init -- need something to set up IPIs, but APIC independent
0000082a T smp_prepare_boot_cpu -- looks OK for Xen, I think
00000066 T smp_prepare_cpus -- need pv_op
So at first pass, it looks like we need 6-8 new pv_ops for SMP, which
isn't very appealing.
Any thoughts about how to come up with a more elegant interface? I'm
digging through smpboot.c and friends, but there's a lot of goo in there...
It's not clear to me what we should do with all the topology stuff.
Clearly a VCPU won't have any fixed physical relationship with other
VCPUs unless they're pinned; I'm wondering if the existing code will
confuse itself if it gets basically random topology info from cpuid.
J
next reply other threads:[~2006-10-19 23:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-19 23:09 Jeremy Fitzhardinge [this message]
2006-10-19 23:34 ` pv_ops smp support Zachary Amsden
2006-10-19 23:48 ` Jeremy Fitzhardinge
2006-10-20 0:02 ` Zachary Amsden
2006-10-20 4:08 ` Jeremy Fitzhardinge
2006-10-20 4:48 ` Zachary Amsden
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=453805BF.80301@goop.org \
--to=jeremy@goop.org \
--cc=chrisw@sous-sol.org \
--cc=rusty@rustcorp.com.au \
--cc=virtualization@lists.osdl.org \
--cc=zach@vmware.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.