Re: [Xen-devel] [PATCH v3 2/2] xen/arm32: implement VFP context switch

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Mon, 2013-06-03 at 15:00 +0100, Julien Grall wrote:
> Add support for VFP context switch on arm32 and a dummy support for arm64
> 
> Signed-off-by: Julien Grall <julien.grall@xxxxxxxxxx>
> 
> Changes in v3:
>     - Add vfp_init to check if the processor supports VFP 3
>     - Add clobber memory
>     - Remove tmps
>     - s/COFNIG_ARM64/CONFIG_ARM64/ in include/asm/arm.h
> 
> Changes in v2:
>     - Fix all the small errors (type, lost headers...)
>     - Add some comments
> ---
>  xen/arch/arm/arm32/Makefile     |    1 +
>  xen/arch/arm/arm32/vfp.c        |   99 
> +++++++++++++++++++++++++++++++++++++++
>  xen/arch/arm/arm64/Makefile     |    1 +
>  xen/arch/arm/arm64/vfp.c        |   13 +++++
>  xen/arch/arm/domain.c           |    7 ++-
>  xen/include/asm-arm/arm32/vfp.h |   41 ++++++++++++++++
>  xen/include/asm-arm/arm64/vfp.h |   16 +++++++
>  xen/include/asm-arm/cpregs.h    |    9 ++++
>  xen/include/asm-arm/domain.h    |    4 ++
>  xen/include/asm-arm/vfp.h       |   25 ++++++++++
>  10 files changed, 214 insertions(+), 2 deletions(-)
>  create mode 100644 xen/arch/arm/arm32/vfp.c
>  create mode 100644 xen/arch/arm/arm64/vfp.c
>  create mode 100644 xen/include/asm-arm/arm32/vfp.h
>  create mode 100644 xen/include/asm-arm/arm64/vfp.h
>  create mode 100644 xen/include/asm-arm/vfp.h
> 
> diff --git a/xen/arch/arm/arm32/Makefile b/xen/arch/arm/arm32/Makefile
> index aaf277a..b903803 100644
> --- a/xen/arch/arm/arm32/Makefile
> +++ b/xen/arch/arm/arm32/Makefile
> @@ -6,5 +6,6 @@ obj-y += proc-ca15.o
>  
>  obj-y += traps.o
>  obj-y += domain.o
> +obj-y += vfp.o
>  
>  obj-$(EARLY_PRINTK) += debug.o
> diff --git a/xen/arch/arm/arm32/vfp.c b/xen/arch/arm/arm32/vfp.c
> new file mode 100644
> index 0000000..2ece43d
> --- /dev/null
> +++ b/xen/arch/arm/arm32/vfp.c
> @@ -0,0 +1,99 @@
> +#include <xen/sched.h>
> +#include <xen/init.h>
> +#include <asm/processor.h>
> +#include <asm/vfp.h>
> +
> +void vfp_save_state(struct vcpu *v)
> +{
> +    v->arch.vfp.fpexc = READ_CP32(FPEXC);
> +
> +    WRITE_CP32(v->arch.vfp.fpexc | FPEXC_EN, FPEXC);
> +
> +    v->arch.vfp.fpscr = READ_CP32(FPSCR);
> +
> +    if ( v->arch.vfp.fpexc & FPEXC_EX ) /* Check for sub-architecture */
> +    {
> +        v->arch.vfp.fpinst = READ_CP32(FPINST);
> +
> +        if ( v->arch.vfp.fpexc & FPEXC_FP2V )
> +            v->arch.vfp.fpinst2 = READ_CP32(FPINST2);
> +        /* Disable FPEXC_EX */
> +        WRITE_CP32((v->arch.vfp.fpexc | FPEXC_EN) & ~FPEXC_EX, FPEXC);
> +    }
> +
> +    /* Save {d0-d15} */
> +    asm volatile("stc p11, cr0, [%0], #32*4"
> +                 : : "r" (v->arch.vfp.fpregs1)
> +                 : "memory");

http://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html suggests that
"=m" (v->arch.vfp.fpregs1) or "=Q" (...) as output constraints might do
the job without clobbering the whole of memory.

I can't see any examples of this on ARM though, e.g. in Linux (other
than =Qo in the atomics) though and I've expected this patter to be
widespread so perhaps that isn't right. Alternatively it's quite a
tricky construct to grep for, so maybe I missed all the uses. We do use
=m a fair bit in x86 Xen FWIW.

> static __init int vfp_init(void)
> +{
> +    unsigned int vfpsid;
> +    unsigned int vfparch;
> +
> +    vfpsid = READ_CP32(FPSID);
> +
> +    printk("VFP implementer 0x%02x architecture %d part 0x%02x variant 0x%x "
> +           "rev 0x%x\n",
> +           (vfpsid & FPSID_IMPLEMENTER_MASK) >> FPSID_IMPLEMENTER_BIT,
> +           (vfpsid & FPSID_ARCH_MASK) >> FPSID_ARCH_BIT,
> +           (vfpsid & FPSID_PART_MASK) >> FPSID_PART_BIT,
> +           (vfpsid & FPSID_VARIANT_MASK) >> FPSID_VARIANT_BIT,
> +           (vfpsid & FPSID_REV_MASK) >> FPSID_REV_BIT);
> +
> +    vfparch = (vfpsid & FPSID_ARCH_MASK) >> FPSID_ARCH_BIT;
> +    if ( vfparch < 2 )
> +        panic("Xen only support VFP 3\n");

Should be "supports". Don't bother resending just for that though.

Ian.


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