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 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).