linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nicolas Pitre <nicolas.pitre@linaro.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Russell King - ARM Linux <linux@arm.linux.org.uk>,
	"arnd@arndb.de" <arnd@arndb.de>,
	"marc.zyngier@arm.com" <marc.zyngier@arm.com>,
	"will.deacon@arm.com" <will.deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"rob.herring@calxeda.com" <rob.herring@calxeda.com>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v6 1/4] arm: introduce psci_smp_ops
Date: Fri, 19 Apr 2013 12:33:22 -0400 (EDT)	[thread overview]
Message-ID: <alpine.LFD.2.03.1304191223280.17375@syhkavp.arg> (raw)
In-Reply-To: <1366388166.29403.2.camel@dagon.hellion.org.uk>

On Fri, 19 Apr 2013, Ian Campbell wrote:

> On Fri, 2013-04-19 at 16:47 +0100, Nicolas Pitre wrote:
> > No one should be probing registers without making sure it is safe to do 
> > so.  Even on non virtualized hardware this can be a dangerous thing to 
> > do.
> 
> Won't people writing per machine code consider, not unreasonably, that
> having been called through a mdesc machine specific hook constitutes
> enough "making sure" that they think it is safe to touch registers which
> are specific to that machine?

Remember that this hook was introduced to decide at run time between 
different possibilities for SMP ops on the _same_ machine configuration.  
That machine shouldn't do things which is not permitted on either 
possible alternatives already.  So far the actual usage of that hook 
only looks in the DT to make a decision.  But even if it were to touch 
the hardware, that means it has to be safe to do so on all the possible 
hardware variations this mdesc is associated to.

And if Xen wants to emulate one of those hardware alternatives, then it 
better be ready to emulate it properly, or manage for _another_ mdesc to 
be selected instead.  That's why mach-virt was introduced.

So in my opinion there is just no issue here.


Nicolas

  reply	other threads:[~2013-04-19 16:33 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-05 13:10 [PATCH 0/4 v6] arm: introduce psci_smp_ops and use them on Xen Stefano Stabellini
2013-04-05 13:11 ` [PATCH v6 1/4] arm: introduce psci_smp_ops Stefano Stabellini
2013-04-18 16:13   ` Russell King - ARM Linux
2013-04-18 16:20     ` Stefano Stabellini
2013-04-18 16:35       ` Nicolas Pitre
2013-04-18 16:49         ` Stefano Stabellini
2013-04-18 17:40           ` Nicolas Pitre
2013-04-22 14:23           ` Russell King - ARM Linux
2013-04-22 14:20         ` Russell King - ARM Linux
2013-04-18 16:40       ` Nicolas Pitre
2013-04-18 17:01         ` Stefano Stabellini
2013-04-18 17:38           ` Nicolas Pitre
2013-04-19  9:40             ` Stefano Stabellini
2013-04-19 15:47               ` Nicolas Pitre
2013-04-19 16:16                 ` [Xen-devel] " Ian Campbell
2013-04-19 16:33                   ` Nicolas Pitre [this message]
2013-04-19 17:06                     ` Stefano Stabellini
2013-04-22 15:21                       ` Ian Campbell
2013-04-22 16:07                         ` Nicolas Pitre
2013-04-24 18:13                           ` Stefano Stabellini
2013-04-25  7:48                           ` Ian Campbell
2013-04-19  9:52             ` Ian Campbell
2013-04-22 14:06       ` Russell King - ARM Linux
2013-04-24 18:25         ` Stefano Stabellini
2013-04-05 13:11 ` [PATCH v6 2/4] arm: prefer psci_smp_ops over mdesc->smp Stefano Stabellini
2013-04-05 16:15   ` Nicolas Pitre
2013-04-05 13:11 ` [PATCH v6 3/4] ARM: Enable selection of SMP operations at boot time Stefano Stabellini
2013-04-09 20:03   ` Nicolas Pitre
2013-04-05 13:11 ` [PATCH v6 4/4] xen/arm: introduce xen_early_init, use PSCI on xen Stefano Stabellini
2013-04-05 16:22   ` Nicolas Pitre
2013-04-05 17:16     ` Stefano Stabellini
2013-04-05 17:34       ` Stefano Stabellini
2013-04-05 19:41         ` Nicolas Pitre
2013-04-05 19:36       ` Nicolas Pitre
2013-04-05 20:50         ` Rob Herring
2013-04-05 21:21           ` Nicolas Pitre
2013-04-05 23:20             ` Stefano Stabellini
2013-04-06  0:15               ` Nicolas Pitre
2013-04-05 23:15           ` Stefano Stabellini
2013-04-05 16:01 ` [PATCH 0/4 v6] arm: introduce psci_smp_ops and use them on Xen Stefano Stabellini
2013-04-08 11:05 ` Stefano Stabellini
2013-04-11  8:25   ` Olof Johansson
2013-04-11 20:16     ` Rob Herring
2013-04-12  8:57       ` Will Deacon
2013-04-12 10:58         ` Stefano Stabellini
2013-04-12 14:13         ` Rob Herring

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=alpine.LFD.2.03.1304191223280.17375@syhkavp.arg \
    --to=nicolas.pitre@linaro.org \
    --cc=Ian.Campbell@citrix.com \
    --cc=Stefano.Stabellini@eu.citrix.com \
    --cc=arnd@arndb.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=marc.zyngier@arm.com \
    --cc=rob.herring@calxeda.com \
    --cc=will.deacon@arm.com \
    --cc=xen-devel@lists.xensource.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).