From: Julien Grall <julien.grall@linaro.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: patches@linaro.org, tim@xen.org,
Stefano.Stabellini@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [PATCH v3 2/2] xen/arm32: implement VFP context switch
Date: Mon, 03 Jun 2013 15:57:11 +0100 [thread overview]
Message-ID: <51ACAEC7.8080705@linaro.org> (raw)
In-Reply-To: <1370270296.24512.25.camel@zakaz.uk.xensource.com>
On 06/03/2013 03:38 PM, Ian Campbell wrote:
> On Mon, 2013-06-03 at 15:32 +0100, Julien Grall wrote:
>> 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@linaro.org>
>>>>
>>>> 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?
>
> I'm not totally confident in this stuff myself....
>
> Apparently the "=" modified means[0] "this operand is write-only for
> this instruction: the previous value is discarded and replaced by output
> data." In the case of a memory constraint you'd want to hope that
> "discarded and replaced" would be equivalent to clobbering the address,
> at least in cases where the compiler knows the size of the thing, as it
> does here.
>
> Ian.
>
> [0] http://gcc.gnu.org/onlinedocs/gcc-4.8.1/gcc/Modifiers.html#Modifiers
>
Shall I use this contrainst for the stc instructions and send a new
patch series?
--
Julien
next prev parent reply other threads:[~2013-06-03 14:57 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-03 14:00 [PATCH v3 0/2] Implement VFP context switch for arm32 Julien Grall
2013-06-03 14:00 ` [PATCH v3 1/2] xen/arm: don't enable VFP on XEN during the boot Julien Grall
2013-06-03 14:00 ` [PATCH v3 2/2] xen/arm32: implement VFP context switch Julien Grall
2013-06-03 14:15 ` Ian Campbell
2013-06-03 14:32 ` Julien Grall
2013-06-03 14:38 ` Ian Campbell
2013-06-03 14:57 ` Julien Grall [this message]
2013-06-03 15:14 ` Ian Campbell
2013-06-03 15:27 ` Julien Grall
2013-06-05 13:06 ` Julien Grall
2013-06-12 15:14 ` Ian Campbell
2013-06-13 16:39 ` Ian Campbell
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=51ACAEC7.8080705@linaro.org \
--to=julien.grall@linaro.org \
--cc=Ian.Campbell@citrix.com \
--cc=Stefano.Stabellini@eu.citrix.com \
--cc=patches@linaro.org \
--cc=tim@xen.org \
--cc=xen-devel@lists.xen.org \
/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).