On Thu, Jun 23, 2022 at 11:29:31AM +0200, Jan Beulich wrote: > On 22.06.2022 17:47, Marek Marczykowski-Górecki wrote: > > On Wed, Jun 15, 2022 at 04:25:54PM +0200, Jan Beulich wrote: > >> On 07.06.2022 16:30, Marek Marczykowski-Górecki wrote: > >>> + memset(xue, 0, sizeof(*xue)); > >>> + > >>> + xue->dbc_ctx = &ctx; > >>> + xue->dbc_erst = &erst; > >>> + xue->dbc_ering.trb = evt_trb; > >>> + xue->dbc_oring.trb = out_trb; > >>> + xue->dbc_iring.trb = in_trb; > >>> + xue->dbc_owork.buf = wrk_buf; > >>> + xue->dbc_str = str_buf; > >> > >> Especially the page-sized entities want allocating dynamically here, as > >> they won't be needed without the command line option requesting the use > >> of this driver. > > > > Are you okay with changing this only in patch 9, where I restructure those > > buffers anyway? > > I'm afraid I'll need to make it to patch 9 to answer this question. If > suitable dealt with later, I don't see a fundamental problem, as long > as it's clear then that I will request that this patch be committed in > a batch with that later one, not in isolation.
This turns out to be rather problematic. xue_uart_init() is called really early (as it should, to get console as early as possible). It's before even boot allocator is functioning, so I can't use alloc_boot_pages(). Are there any other options for memory allocations at this point? We are talking about 58 pages. It isn't much, but isn't exactly nothing either. Maybe there is way to keep the memory allocated statically as it is now, but return it to the allocator is xue is _not_ enabled? -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab
signature.asc
Description: PGP signature
