Re: [Xen-devel] [PATCH v3] [RFC] arm: use PSCI if available

[Will Deacon <will.deacon@xxxxxxx>]

On Wed, Mar 27, 2013 at 04:23:15PM +0000, Stefano Stabellini wrote:
> OK, let's see if I can make this acceptable to you.
> 
> 
> Would you agree on a patch that moves virt_smp_ops out of mach-virt and
> renames them to psci_smp_ops (maybe to arch/arm/kernel/psci_smp_ops.c)?

Moving the code out of psci.c is certainly a good first step, yes.

> Would you agree on initializing psci from setup_arch, right after the
> call to arm_dt_init_cpu_maps()?

Hmmm. An early_initcall runs before SMP is up, so why do you need this
earlier than that? Is it because you don't want to set the SMP ops later on?

> Finally the most controversial point: would you agree on using
> psci_smp_ops by default if they are available?
> If not, would you at least agree on letting Xen overwrite the default
> machine smp_ops?
> We need one or the other for dom0 support.

Again, I think there needs to be a dummy layer between the smp_ops and PSCI,
rather than assigning the things directly if we're going to use this as a
default implementation. I still question whether default PSCI operations make
any sense though... I understand that you're currently saying `yes, Xen can
use the same firmware interface as KVM' but will that always be true? What
happens when we want to run virtual machines on multi-cluster platforms, for
example? Will KVM and Xen make sure that CPU affinities are described in the
same way? What if one or the other decides to pass side-band information in
the power_state parameters?

In all of these cases, we'd have to split the code back up, so I don't see
any long-term value in consolidating everything just because it might be
possible today. The real problem you're trying to solve seems to stem from
patching the smp_ops in your dom0 kernel. Can you elaborate a bit more on
what's going on here please? How would having PSCI default smp_ops help you?

Cheers,

Will

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel