x86: Add sysctl knobs for loader tunables

[zlei]

Summary

The following loader tunable do not have corresponding sysctl MIB
entries. Add them so that they can be retrieved, and sysctl -T will
also report them correctly.

1. hw.attach_intel_csr_pci
2. hw.cpu_stdext_disable
3. hw.dmar.enable
4. hw.dmar.fault_log_size
5. hw.dmar.ir
6. hw.dmar.pmr.disable
7. hw.dmar.qi
8. hw.dmar.qi_size
9. hw.x2apic_enable

MFC after: 1 week

[zlei]

sys/x86/iommu/intel_drv.c

163

I guess those knobs hw.dmar.xxx should be under hw.iommu.dmar.

[zlei]

sys/x86/iommu/intel_drv.c

163

I guess those knobs hw.dmar.xxx should be under hw.iommu.dmar.

Found a history change https://reviews.freebsd.org/D25807 .

So how should we process the inconsistency ?
Maybe with a compile condition COMPAT_FREEBSD10 ?

+#ifdef COMPAT_FREEBSD10
        TUNABLE_UINT64_FETCH("hw.dmar.timeout", &timeout);
+#endif
+       TUNABLE_UINT64_FETCH("hw.iommu.dmar.timeout", &timeout);

[zlei]

sys/x86/acpica/madt.c

200

Emm, we already have hw.apic.x2apic_mode, a hw.x2apic_enable seems redundant .

[zlei]

Quote from D42233 by @kib

That said, I do not see much use for these and other x86-related tunables to be exposed as sysctl. They are debugging tools, useful only for people who understand the code.

[kib]

sys/x86/iommu/intel_drv.c

163

well, iommu == dmar.

So if you want to rename, do it by hw.dmar => hw.iommu or hw.iommu.intel (because for AMD it would be different)

COMPAT_FREEBSD10 does not make sense since it is present in 14 as well. But IMO this should not be kept, just rename the knobs. People that use them should know what they do, it is not a typical user tweak.

sys/x86/pci/qpi.c

65

Again not too useful. Either buses are attached and knob worked, or there are no buses visible.

sys/x86/x86/identcpu.c

1523

Not too useful to provide.