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