|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v5 04/10] vpci: Refactor REGISTER_VPCI_INIT
On 2025/6/9 17:29, Roger Pau Monné wrote:
> On Mon, Jun 09, 2025 at 07:50:21AM +0000, Chen, Jiqian wrote:
>> On 2025/6/6 17:14, Roger Pau Monné wrote:
>>> On Fri, Jun 06, 2025 at 09:05:48AM +0200, Jan Beulich wrote:
>>>> On 06.06.2025 08:29, Chen, Jiqian wrote:
>>>>> On 2025/6/5 20:50, Roger Pau Monné wrote:
>>>>>> On Mon, May 26, 2025 at 05:45:53PM +0800, Jiqian Chen wrote:
>>>>>>> + }; \
>>>>>>> + static vpci_capability_t *const finit##_entry \
>>>>>>> + __used_section(".data.vpci") = &finit##_t
>>>>>>
>>>>>> IMO this should better use .rodata instead of .data.
>>>>> Is below change correct?
>>>>>
>>>>> + static const vpci_capability_t *const finit##_entry \
>>>>> + __used_section(".rodata") = &finit##_t
>>>>
>>>> No, specifically because ...
>>>>
>>>>>> Not that it matters much in practice, as we place it in .rodata anyway.
>>>>>> Note
>>>>>> however you will have to move the placement of the VPCI_ARRAY in the
>>>>>> linker script ahead of *(.rodata.*), otherwise that section match will
>>>>>> consume the vPCI data.
>>>>> I am sorry, how to move it ahead of *(.rodata.*) ?
>>>>> Is below change correct?
>>>>>
>>>>> diff --git a/xen/include/xen/xen.lds.h b/xen/include/xen/xen.lds.h
>>>>> index 793d0e11450c..3817642135aa 100644
>>>>> --- a/xen/include/xen/xen.lds.h
>>>>> +++ b/xen/include/xen/xen.lds.h
>>>>> @@ -188,7 +188,7 @@
>>>>> #define VPCI_ARRAY \
>>>>> . = ALIGN(POINTER_ALIGN); \
>>>>> __start_vpci_array = .; \
>>>>> - *(SORT(.data.vpci.*)) \
>>>>> + *(.rodata) \
>>>>
>>>> ... this isn't - you'd move _all_ of .rodata into here, which definitely
>>>> isn't what you want. What I understand Roger meant was a .rodata-like
>>>> section, e.g. .rodata.vpci.* (much like it was .data.vpci.* before).
>>>
>>> Indeed, my suggestion was merely to use .rodata instead of .data, as
>>> that's more accurate IMO. I think it should be *(.rodata.vpci) (and
>>> same section change for the __used_section() attribute.
>>
>> If I understand correctly, the next version will be:
>>
>> + static const vpci_capability_t *const finit##_entry \
>> + __used_section(".rodata.vpci") = &finit##_t
>> +
>>
>> and
>>
>> #define VPCI_ARRAY \
>> . = ALIGN(POINTER_ALIGN); \
>> __start_vpci_array = .; \
>> - *(SORT(.data.vpci.*)) \
>> + *(.rodata.vpci) \
>> __end_vpci_array = .;
>
> Did you also move the instances of VPCI_ARRAY in the linker scripts so
> it's before the catch-all *(.rodata.*)?
>
>>
>> But, that encountered an warning when compiling.
>> " {standard input}: Assembler messages:
>> {standard input}:1160: Warning: setting incorrect section attributes for
>> .rodata.vpci
>> {standard input}: Assembler messages:
>> {standard input}:3034: Warning: setting incorrect section attributes for
>> .rodata.vpci
>> {standard input}: Assembler messages:
>> {standard input}:6686: Warning: setting incorrect section attributes for
>> .rodata.vpci "
>
> What are the attributes for .rodata.vpci in the object files? You can
> get those using objdump or readelf, for example:
>
> $ objdump -h xen/drivers/vpci/msi.o
> [...]
> 17 .data.vpci.9 00000008 0000000000000000 0000000000000000 00000a50 2**3
> CONTENTS, ALLOC, LOAD, RELOC, DATA
>
> It should be READONLY, otherwise you will get those messages.
>
>> And, during booting Xen, all value of __start_vpci_array is incorrect.
>> Do I miss anything?
>
> I think that's likely because you haven't moved the instance of
> VPCI_ARRAY in the linker script?
Oh, right. Sorry, I forgot to move it.
After changing this, it works now.
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index bf956b6c5fc0..c88fd62f4f0d 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -134,6 +134,7 @@ SECTIONS
BUGFRAMES
*(.rodata)
+ VPCI_ARRAY
*(.rodata.*)
*(.data.rel.ro)
*(.data.rel.ro.*)
@@ -148,7 +149,6 @@ SECTIONS
*(.note.gnu.build-id)
__note_gnu_build_id_end = .;
#endif
- VPCI_ARRAY
} PHDR(text)
>
> Thanks, Roger.
--
Best regards,
Jiqian Chen.
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |