From: Jeremy Fitzhardinge <jeremy@goop.org>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@linux.intel.com>,
Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCH 01/13] [VOYAGER] x86: add {safe,hard}_smp_processor_id to smp_ops
Date: Sun, 08 Mar 2009 10:15:11 -0700 [thread overview]
Message-ID: <49B3FD1F.9010000@goop.org> (raw)
In-Reply-To: <1236530906-7175-2-git-send-email-James.Bottomley@HansenPartnership.com>
James Bottomley wrote:
> Not having apics, Voyager can't use the default apic implementation of
> these, it has to read from a special port in the VIC to get the
> processor ID, so abstract these functions in smp_ops to allow voyager
> to live simultaneously with the apic code.
>
These aren't performance-sensitive at all, are they? smp_ops is not
subject to patching/inlining optimisations happen to more hotpath pvops.
Is safe_smp_processor_id needed at all? It's only got two callers, and
x86-64 just implements it as smp_processor_id().
> diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
> index 035582a..0dfb8c0 100644
> --- a/arch/x86/xen/smp.c
> +++ b/arch/x86/xen/smp.c
> @@ -450,6 +450,11 @@ static irqreturn_t xen_call_function_single_interrupt(int irq, void *dev_id)
> return IRQ_HANDLED;
> }
>
> +static int xen_hard_smp_processor_id(void)
> +{
> + return read_apic_id();
> +}
> +
> static const struct smp_ops xen_smp_ops __initdata = {
> .smp_prepare_boot_cpu = xen_smp_prepare_boot_cpu,
> .smp_prepare_cpus = xen_smp_prepare_cpus,
> @@ -465,6 +470,8 @@ static const struct smp_ops xen_smp_ops __initdata = {
>
> .send_call_func_ipi = xen_smp_send_call_function_ipi,
> .send_call_func_single_ipi = xen_smp_send_call_function_single_ipi,
> + .hard_smp_processor_id = xen_hard_smp_processor_id,
> + .safe_smp_processor_id = apic_safe_smp_processor_id,
>
Hm, there's no meaningful apic-based implementation for these under
Xen. DomU has no access to apics, and Dom0's vcpus don't have any fixed
relationship to physical cpu apics. They should both just return
smp_processor_id(), I guess.
J
next prev parent reply other threads:[~2009-03-08 17:15 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-08 16:48 [PATCH 00/13] convert voyager over to the x86 quirks model James Bottomley
2009-03-08 16:48 ` [PATCH 01/13] [VOYAGER] x86: add {safe,hard}_smp_processor_id to smp_ops James Bottomley
2009-03-08 16:48 ` [PATCH 02/13] [VOYAGER] x86/mca: make mca_nmi_hook external James Bottomley
2009-03-08 16:48 ` [PATCH 03/13] [VOYAGER] x86: add prefill_possible_map to x86_quirks James Bottomley
2009-03-08 16:48 ` [PATCH 04/13] [VOYAGER] x86: use boot_cpu_id instead of zero for checking boot processor James Bottomley
2009-03-08 16:48 ` [PATCH 05/13] [VOYAGER] x86/voyager: Move voyager detection to a new bootparam area James Bottomley
2009-03-08 16:48 ` [PATCH 06/13] [VOYAGER] x86: eliminate subarchitecture file setup_arch.h James Bottomley
2009-03-08 16:48 ` [PATCH 07/13] [VOYAGER] x86: eliminate subarchitecture file entry_arch.h James Bottomley
2009-03-08 16:48 ` [PATCH 08/13] [VOYAGER] x86: eliminate subarchitecture file do_timer.h James Bottomley
2009-03-08 16:48 ` [PATCH 09/13] [VOYAGER] x86: redo irq2 cascade setup James Bottomley
2009-03-08 16:48 ` [PATCH 10/13] [VOYAGER] x86: make disabling the apics functional instead of a flag James Bottomley
2009-03-08 16:48 ` [PATCH 11/13] [VOYAGER] x86/Voyager: add missing QIC call function single gate James Bottomley
2009-03-08 16:48 ` [PATCH 12/13] [VOYAGER] x86/Voyager: replace inline io area reads with readX accessors James Bottomley
2009-03-08 16:48 ` [PATCH 13/13] [VOYAGER] x86/Voyager: Plumb voyager back into the build James Bottomley
2009-03-08 17:15 ` Jeremy Fitzhardinge [this message]
2009-03-08 17:23 ` [PATCH 01/13] [VOYAGER] x86: add {safe,hard}_smp_processor_id to smp_ops James Bottomley
2009-03-09 20:54 ` [PATCH 00/13] convert voyager over to the x86 quirks model Sam Ravnborg
2009-03-10 21:58 ` Yinghai Lu
2009-03-10 22:02 ` James Bottomley
2009-03-10 22:37 ` Ingo Molnar
2009-03-11 15:41 ` James Bottomley
2009-03-11 17:26 ` H. Peter Anvin
2009-03-11 18:53 ` James Bottomley
2009-03-11 22:55 ` Ingo Molnar
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=49B3FD1F.9010000@goop.org \
--to=jeremy@goop.org \
--cc=James.Bottomley@HansenPartnership.com \
--cc=hpa@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
/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