|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v3 2/2] xen/arm32: implement VFP context switch
On 06/03/2013 03:15 PM, Ian Campbell wrote:
> 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'm not sure to fully understand the concept behind "=m". Does it mean
that gcc will clobber all the memory range addressed by fpregs?
--
Julien
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |