Re: [Xen-devel] [PATCH v6 02/15] xen/arm: basic PSCI support, implement cpu_on and cpu_off

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2013-05-07 at 12:50 +0100, Julien Grall wrote:
> On 05/03/2013 11:51 AM, Stefano Stabellini wrote:
> 
> > diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c
> > new file mode 100644
> > index 0000000..562ef0b
> > --- /dev/null
> > +++ b/xen/arch/arm/psci.c
> > @@ -0,0 +1,76 @@
> > +/*
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#include <xen/errno.h>
> > +#include <xen/sched.h>
> > +#include <xen/types.h>
> > +
> > +#include <asm/current.h>
> > +#include <asm/psci.h>
> > +
> > +int do_psci_cpu_on(uint32_t vcpuid, register_t entry_point)
> 
> 
> I have a compilation error on arm64, here you define entry_point as
> register_t but when you declare the prototype (see below), you use uint32_t.
> 
> > diff --git a/xen/include/asm-arm/psci.h b/xen/include/asm-arm/psci.h
> > new file mode 100644
> > index 0000000..8511eb1
> > --- /dev/null
> > +++ b/xen/include/asm-arm/psci.h
> > @@ -0,0 +1,24 @@
> > +#ifndef __ASM_PSCI_H__
> > +#define __ASM_PSCI_H__
> > +
> > +#define PSCI_SUCCESS  0
> > +#define PSCI_ENOSYS  -1
> > +#define PSCI_EINVAL  -2
> > 4 th eu+#define PSCI_DENIED  -3
> > +
> > +int do_psci_cpu_on(uint32_t vcpuid, uint32_t entry_point);
> 
> 
> Prototype here.
> 
> > +int do_psci_cpu_off(uint32_t power_state);
> > +int do_psci_cpu_suspend(uint32_t power_state, uint32_t entry_point);
> 
> 
> Same for do_psci_cpu_suspend, entry_point should be register_t.

Logically it might even be a vaddr_t (although the distinction is
perhaps rather moot in this context, given that the virtual address in
question is going to be written to the pc register).

However the PSCI interface doesn't seem to be 32/64 clean (i.e. this
argument varies with the calling arch), I hope we can paper over that
fairly easily.

Ian.

> 
> > +int do_psci_migrate(uint32_t vcpuid);
> > +
> 
> 



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