[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v7 0/5] xen/arm: Add GICv3 support



On Wed, Jul 16, 2014 at 7:02 PM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> On Wed, 2014-07-16 at 13:38 +0100, Ian Campbell wrote:
>> On Wed, 2014-07-16 at 17:17 +0530, Vijay Kilari wrote:
>> > On Wed, Jul 16, 2014 at 4:05 PM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> 
>> > wrote:
>> > > On Fri, 2014-07-11 at 18:21 +0530, vijay.kilari@xxxxxxxxx wrote:
>> > >> Add GICv3 support for arm64 platform.
>> > >
>> > > I get lots of:
>> > > {standard input}:1476: Error: unknown or missing system register name at 
>> > > operand 1 -- `msr ICH_VMCR_EL2,x1'
>> > >
>> > > I'm using:
>> > > $ aarch64-linux-gnu-gcc --version
>> > > aarch64-linux-gnu-gcc (crosstool-NG linaro-1.13.1-4.8-2014.04 - Linaro 
>> > > GCC 4.8-2014.04) 4.8.3 20140401 (prerelease)
>> > >
>> > > Do you have a pointer to a toolchain which can build this stuff?
>> >
>> >   I am using our internal toolchain based on GCC version 4.7
>>
>> OK. We really ought to find some publicly available toolchain before
>> accepting this code. Or else we need to make gic v3 functionality depend
>> on the toolstack, which would suck.
>>
>> I'm going to see if the Linaro 4.9 gcc will do it.
>
> Sadly not.
>
> Mark Rutland pointed me to the workaround which Linux uses:
> https://git.kernel.org/cgit/linux/kernel/git/maz/arm-platforms.git/tree/include/linux/irqchip/arm-gic-v3.h?h=gicv3/base&id=1545387f2ca2e51f5ccd3ed764348ee41e15c02f#n143
>
> Which AFAICT works with at least Linaro's gcc 4.8 and 4.9. So I think
> we'll have to go down this route.
>
> Please could you make sure that this series compiles with the gcc from
> either http://releases.linaro.org/14.04/components/toolchain/binaries
> or
> http://releases.linaro.org/14.06/components/toolchain/binaries
>
> Presumably this will mostly be a case of adding the defines to
> xen/include/asm-arm/sysregs.h.

   After adding assembler aliases to GIC sysregs similar to Mark's workaround,
I observed that existing READ_SYSREG{32,64} and WRITE_SYSREG{32,64}
macros does not replace the assembler aliases. Instead register names are kept
as it is.

However {READ,WRITE}_SYSREG macros works because these macros
are again replaced with {READ,WRITE}_SYSREG64 macro. So pre-processor
will replace the sys register name with assembler alias when replacing
{READ,WRITE}_SYSREG macro with {READ,WRITE}_SYSREG64 macro

I propose to change existing READ_SYSREG{32,64} and WRITE_SYSREG{32,64}
macros

+#define __stringyfy(x) #x
 /* Access to system registers */

 #define READ_SYSREG32(name) ({                          \
     uint32_t _r;                                        \
-    asm volatile("mrs  %0, "#name : "=r" (_r));         \
+    asm volatile("mrs  %0, "__stringyfy(name) : "=r" (_r));         \
     _r; })
 #define WRITE_SYSREG32(v, name) do {                    \
     uint32_t _r = v;                                    \
-    asm volatile("msr "#name", %0" : : "r" (_r));       \
+    asm volatile("msr "__stringyfy(name)", %0" : : "r" (_r));       \
 } while (0)

 #define WRITE_SYSREG64(v, name) do {                    \
     uint64_t _r = v;                                    \
-    asm volatile("msr "#name", %0" : : "r" (_r));       \
+    asm volatile("msr "__stringyfy(name)", %0" : : "r" (_r));       \
 } while (0)
 #define READ_SYSREG64(name) ({                          \
     uint64_t _r;                                        \
-    asm volatile("mrs  %0, "#name : "=r" (_r));         \
+    asm volatile("mrs  %0, "__stringyfy(name) : "=r" (_r));         \
     _r; })

May be __stringyfy macro can be added to separate header
file similar to kernel?

Regards
Vijay

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.