On 15/07/2022 11:51, Jan Beulich wrote:
> On 15.07.2022 12:43, Andrew Cooper wrote:
>> On 15/07/2022 11:14, Jan Beulich wrote:
>>> On 14.07.2022 16:39, Anthony PERARD wrote:
>>>> --- a/xen/tools/check-endbr.sh
>>>> +++ b/xen/tools/check-endbr.sh
>>>> @@ -78,7 +78,7 @@ then
>>>> else
>>>> grep -aob -e "$(printf '\363\17\36\372')" -e "$(printf
>>>> '\363\17\36\373')" \
>>>> -e "$(printf '\146\17\37\1')" $TEXT_BIN
>>>> -fi | awk -F':' '{printf "%s%x\n", "'$vma_hi'", int(0x'$vma_lo') + $1}' >
>>>> $ALL
>>>> +fi | awk -F':' '{printf "%s%x\n", "'$vma_hi'", int('$((0x$vma_lo))') +
>>>> $1}' > $ALL
>>> I'm afraid that's not portable to environments where sizeof(long) < 8.
>>> The shell isn't required to use wider than long for the evaluation.
>> Yuck. This works at the moment in 32 bit builds because:
>>
>> ++ objdump -j .text xen-syms -h
>> ++ awk '$2 == ".text" {printf "vma_hi=%s\nvma_lo=%s\n", substr($4, 1,
>> 8), substr($4, 9, 16)}'
>> + eval vma_hi=ffff82d0 vma_lo=40200000
>> ++ vma_hi=ffff82d0
>> ++ vma_lo=40200000
>>
>> so the top bit isn't set.
>>
>> And going from an 8/8 split to a 9/7 split doesn't work either because
>> that uses 4 bits and we've only got 2 to play with given .text's 1G
>> alignment.
> Why does text alignment matter here? All we care about are offsets
> into the Xen image. An I guess we aren't really at risk of going
> beyond 256M in image size ...
Very good point, but it's not even the image size. It's only .text.
Furthermore, we can have the safety check for that in this script too.
Lemme see what I can do.
>> I know it's disgusting, but how about a BUILD_BUG_ON(XEN_VIRT_START &
>> (1u << 31)) ?
> In the worst case, why not. But that would be an odd restriction on
> changes to the memory layout (which we've done in the past).
I did say disgusting... I'm entirely happy that it doesn't appear to be
needed.
~Andrew
