From: George Dunlap <george.dunlap@eu.citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Julien Grall <julien.grall@citrix.com>,
"Tim (Xen.org)" <tim@xen.org>,
xen-devel <xen-devel@lists.xen.org>,
"Keir (Xen.org)" <keir@xen.org>,
Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [PATCH 00/03 V2] arm: host SMP support
Date: Wed, 17 Apr 2013 14:45:46 +0100 [thread overview]
Message-ID: <516EA78A.9090800@eu.citrix.com> (raw)
In-Reply-To: <1366205327.25579.41.camel@zakaz.uk.xensource.com>
On 17/04/13 14:28, Ian Campbell wrote:
> On Wed, 2013-04-17 at 14:20 +0100, George Dunlap wrote:
>> On 17/04/13 13:52, Ian Campbell wrote:
>>> Most of v1 one went in already. This rebases Rebases the remainder of v1
>>> and addressed the comments by dropping the use of the GROUP1 bit.
>>>
>>> I think SMP is a substantial feature of Xen on ARM for 4.3 and it is
>>> therefore worthy of a freeze exception. It touches only ARM specific
>>> code.
>> Yeah, I think ARM without SMP is almost a bug. :-) So for this series:
>>
>> Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
>>
>>> I would like to apply Julien's "implement smp_call_function" series[0]
>>> on top of it which fixes reboot/shutdown but which makes the x86
>>> smp_call_function generic and so necessarily touches x86 and generic
>>> code. If that is considered too risky (I personally think it should be
>>> OK, it's a pretty obvious move) then we could duplicate that code for
>>> ARM.
>>>
>>> [0] v2 at <1366119508-9227-3-git-send-email-julien.grall@citrix.com>
>> Let me take a look. The most important question is, if there's a bug,
>> will we find it before the release? Since smp_call_function() is called
>> by basically everyone all the time, I think we can be pretty confident
>> that we'll find any bugs in x86 code. Would you agree?
> It's not called much on ARM but I believe it is on x86 so Yes.
>
> It is also a pretty simple move with the only change being to refactor
> the one arch specific line in to a per arch function.
If Keir or Jan think that if there is a regression we are highly likely
to catch it before the release, I'm OK with Julien's series.
-George
prev parent reply other threads:[~2013-04-17 13:45 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-17 12:52 [PATCH 00/03 V2] arm: host SMP support Ian Campbell
2013-04-17 12:52 ` [PATCH 1/3] arm: gic: implement IPIs using SGI mechanism Ian Campbell
2013-04-18 11:38 ` Stefano Stabellini
2013-04-17 12:52 ` [PATCH 2/3] arm64: correct secondary CPU bringup Ian Campbell
2013-04-17 12:52 ` [PATCH 3/3] arm: vgic: fix race in vgic_vcpu_inject_irq Ian Campbell
2013-04-18 14:16 ` Ian Campbell
2013-04-17 13:20 ` [PATCH 00/03 V2] arm: host SMP support George Dunlap
2013-04-17 13:28 ` Ian Campbell
2013-04-17 13:45 ` George Dunlap [this message]
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=516EA78A.9090800@eu.citrix.com \
--to=george.dunlap@eu.citrix.com \
--cc=Ian.Campbell@citrix.com \
--cc=Stefano.Stabellini@eu.citrix.com \
--cc=julien.grall@citrix.com \
--cc=keir@xen.org \
--cc=tim@xen.org \
--cc=xen-devel@lists.xen.org \
/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.