On 05.06.2025 16:51, Marek Marczykowski-Górecki wrote:
> On Thu, Jun 05, 2025 at 04:42:53PM +0200, Jan Beulich wrote:
>> On 26.05.2025 17:39, Marek Marczykowski-Górecki wrote:
>>> On Mon, May 26, 2025 at 04:08:17PM +0100, Andrew Cooper wrote:
>>>> On 25/05/2025 3:15 pm, Marek Marczykowski-Górecki wrote:
>>>>> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
>>>>> index 25189541244d..3ef819a252e4 100644
>>>>> --- a/xen/arch/x86/setup.c
>>>>> +++ b/xen/arch/x86/setup.c
>>>>> @@ -1481,6 +1481,8 @@ void asmlinkage __init noreturn __start_xen(void)
>>>>> highmem_start &= ~((1UL << L3_PAGETABLE_SHIFT) - 1);
>>>>> #endif
>>>>>
>>>>> + console_init_pre_relocate();
>>>>> +
>>>>> /*
>>>>> * Iterate backwards over all superpage-aligned RAM regions.
>>>>> *
>>>>> @@ -1606,6 +1608,12 @@ void asmlinkage __init noreturn __start_xen(void)
>>>>> if ( !xen_phys_start )
>>>>> panic("Not enough memory to relocate Xen\n");
>>>>>
>>>>> + /*
>>>>> + * Notify console drivers about relocation, before reusing old Xen's
>>>>> + * memory.
>>>>> + */
>>>>> + console_init_post_relocate();
>>>>> +
>>>>
>>>> With reference to the next patch, there are printk()'s in this region
>>>> which want to work (in case something goes very wrong), so I don't think
>>>> setting dbc->suspended is the best approach.
>>>
>>> I guess the post_relocate hook might be moved a bit earlier, but still,
>>> once relocation happens, the xhci console is not functional until it
>>> gets relocated too (for example - it would post new TRBs into a ring
>>> that isn't actually monitored by the controller).
>>
>> 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.
Jan
