On 06.06.2025 17:54, Marek Marczykowski-Górecki wrote: > On Fri, Jun 06, 2025 at 08:26:33AM +0200, Jan Beulich wrote: >> On 05.06.2025 18:08, Marek Marczykowski-Górecki wrote: >>> On Thu, Jun 05, 2025 at 06:05:02PM +0200, Jan Beulich wrote: >>>> On 05.06.2025 16:51, Marek Marczykowski-Górecki wrote: >>>>> On Thu, Jun 05, 2025 at 04:42:53PM +0200, Jan Beulich wrote: >>>>>> Why is it that this ring is dependent upon Xen's position? If the ring >>>>>> was >>>>>> dynamically allocated, it wouldn't change position when Xen is moved. >>>>> >>>>> The console is setup quite early, I don't think I can allocate memory at >>>>> this stage, no? >>>> >>>> But you allocate before Xen is moved, I suppose. >>> >>> Well, I have those buffers in BSS exactly to avoid the need to allocate >>> them (or rather: have bootloader allocate them for me). >> >> Yet them remaining in .bss is now getting in the way. Imo moving them to >> .init.* and adding proper allocation is going to be easier than the hook- >> ary you are proposing. > > So, when would you propose to allocate them? Wouldn't that be yet > another hook?
Exactly one, yes. Given Andrew's earlier reply my understanding was that to get things correct in your proposed model would end up requiring more than one. However, the point in time where move_xen() is called is still too early to allocate memory a (somewhat) normal way - even the boot allocator gets seeded only later. So I guess console_init_preirq() may need to inform its caller how much memory is going to be needed later on (and what address constraints there are, if any). Then a suitable chunk would need setting aside kind of like it's done for kexec. That address would then need to be passed into the new hook. Jan
