Re: [PATCH v6 2/3] xen/arm: Enable the existing x86 virtual PCI support for ARM.

[Jan Beulich <jbeulich@xxxxxxxx>]

On 15.10.2021 01:49, Stefano Stabellini wrote:
> On Thu, 14 Oct 2021, Bertrand Marquis wrote:
>> --- a/xen/include/public/arch-arm.h
>> +++ b/xen/include/public/arch-arm.h
>> @@ -418,6 +418,13 @@ typedef uint64_t xen_callback_t;
>>  #define GUEST_GICV3_GICR0_BASE     xen_mk_ullong(0x03020000) /* vCPU0..127 
>> */
>>  #define GUEST_GICV3_GICR0_SIZE     xen_mk_ullong(0x01000000)
>>  
>> +/*
>> + * 256 MB is reserved for VPCI configuration space based on calculation
>> + * 256 buses × 32 devices × 8 functions × 4 KB = 256 MB
>> + */
> 
> Somehow 3 non-ascii characters sneaked into this patch. The 'x' are not
> 'x' but are 0xc3 and cause the following errors in a few gitlab-ci
> builds:
> 
> python3 mkheader.py arm32 arm32.h.tmp 
> /builds/xen-project/people/sstabellini/xen/tools/include/xen-foreign/../../../xen/include/public/arch-arm.h
>  
> /builds/xen-project/people/sstabellini/xen/tools/include/xen-foreign/../../../xen/include/public/xen.h
> Traceback (most recent call last):
>   File "mkheader.py", line 120, in <module>
>     input += f.read();
>   File "/usr/lib/python3.5/encodings/ascii.py", line 26, in decode
>     return codecs.ascii_decode(input, self.errors)[0]
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 14641: 
> ordinal not in range(128)
> Makefile:28: recipe for target 'arm32.h' failed
> make[2]: *** [arm32.h] Error 1
> 
> Full logs here:
> https://gitlab.com/xen-project/people/sstabellini/xen/-/pipelines/38855078
> https://gitlab.com/xen-project/people/sstabellini/xen/-/jobs/16810108756
> 
> 
> Replacing the 3 characters with 'x' solves the problem.
> https://gitlab.com/xen-project/people/sstabellini/xen/-/pipelines/388721262

Interesting. I thought we permit UTF-8 in the sources; see e.g.
tools/tests/x86_emulator/simd-sha.c using Σ. Is mkheader.py in need
of adjustment? Of course I can see that right now the easiest is to
use ASCII x, but I think it was deliberate to use × here.

Then again, with the goal of the public headers being usable with
pretty old compilers as well (C89 being the assumed baseline),
excluding them from the permission to use UTF-8 may also be quite
reasonable.

Jan