Re: lapic detection at runtime for kernel modules

[Emile `iMil' Heitor <imil%home.imil.net@localhost>]

Hey Jean-Yves!

On Thu, 20 Mar 2025, Jean-Yves Migeon (NetBSD) wrote:

> I would say yes (assumption), however note that it depends on caller's 
> context especially if it passes down curcpu() or another reference, or 
> iterates with CPU_INFO_FOREACH(...). In that case I would
>
>    KASSERT(kpreempt_disabled()) or KASSERT(mutex_owned(&cpu_lock))
>
> at the beginning if you expect it to be used in paths with these properties 
> (especially kernel preemption -- I don't think &cpu_lock is expected for that 
> case alone).
>
> I guess that your intent is to use the LAPIC check to set the leaf regs 
> afterwards, but as there is no way to ensure the cpu_info passed as ref is 
> the one from the same curcpu()... hence my recommendation for the kpreempt 
> check

Thanks for the detailed explaination.

After some back and forth, mlelstv@ came with the most elegant idea:
https://imil.net/NetBSD/has_lapic.patch
Basically an #ifdef function translation, as the point is only to know
if we have LAPIC support enabled in the kernel, which AFAIK is only
false in Xen... but do we build nvmm module for Xen?

Cheers,

------------------------------------------------------------------------
Emile `iMil' Heitor <imil@{home.imil.net,NetBSD.org}> | https://imil.net