Re: lapic detection at runtime for kernel modules

Oh hai,

Le 16/03/2025 à 07:45, Emile `iMil' Heitor a écrit :
> I'm in the process of adding support for CPUID leaf 0x40000010 in the
> NVMM hypervisor.
> This leaf forwards TSC and LAPIC frequency from the host machine to
> the guest in order to avoid their computation and gain speed at boot
> time. This is easily done in sys/dev/nvmm/x86/nvmm_x86_{svm,vmx}.c
> 
> cpudata->gprs[NVMM_X64_GPR_RAX] = curcpu()->ci_data.cpu_cc_freq / 1000;
> cpudata->gprs[NVMM_X64_GPR_RBX] = lapic_per_second / 1000;
> 
> [...]
> for nvmm and check for lapic presence at runtime.
> I came up with the following piece of code to achieve just that:
> 
> static bool
> cpu_has_lapic(struct cpu_info *ci)
> {
>      int i;
>      struct intrsource *isp;
> 
>      for (i = 0; i < MAX_INTR_SOURCES; i++) {
>          isp = ci->ci_isources[i];
>          if (isp == NULL)
>              continue;
>          if (isp->is_pic->pic_type == PIC_LAPIC)
>              return true;
>      }
>      return false;
> }
> 
> Does this seem reasonable?

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

Cheers (:

-- 
jym@