Reduce amount of -no-integrated-as on x86 as .code16 is now supported by
LLVM.

branches: 1.8.2; 1.8.12; 1.8.16;
fix typo, revert to previous version

revert previous; bug was in the position of the inclusion of the file.

Don't depend on the .d file here; since this is the only rule, acpi_wakeup.d
will never be build!

LLVM's assembler parser doesn't support .code32 yet, so disable it as
needed.

branches: 1.4.2; 1.4.6; 1.4.8;
Use sed, awk and hexdump from tools to make this work on Solaris. Ok by apb.

branches: 1.3.4; 1.3.6; 1.3.16; 1.3.24; 1.3.26;
MAKEVERBOSE support

branches: 1.2.2;
How did these get lost?

branches: 1.1.2; 1.1.8; 1.1.10; 1.1.12;
file Makefile.wakecode.inc was initially added on branch jmcneill-pm.

Normalize some machine dependent CPU frequenct sysctl variables.

This moves machdep.*.frequency.* to machdep.cpu.frequency.*.

This was proposed on tech-kern some time ago. The intention is to allow
third-party tools such as estd and conky to more easily and reliably
fetch or modify the current CPU frequency without iterating through
various machine-dependent variables to check their presence.

PR kern/55080: current does not boot

Back out previous. To be addressed differently.

Put ACPI idle under ACPICPU_ENABLE_C3 until the wrinkles are ironed out.
This seems well written and basically all good, but currently doesn't enter
a low power state, and imposes a big performance penalty. Proposed on
port-i386 & port-amd64.

Add the __nocsan attribute on this function. Races on ci_want_resched are
accepted (part of the design).

xc_barrier - convenience function to xc_broadcast() a nop.

Make the intent more clear and also avoid a bunch of (xcfunc_t)nullop
casts that gcc 8 -Wcast-function-type is not happy about.

Remove unused cpu_msr.h includes.

branches: 1.78.14; 1.78.16;
Add a synthesized pc beeper and keyboard bell for platforms with an audio
device.

branches: 1.77.4; 1.77.8;
CID/1203191: Out of bounds read

branches: 1.76.2;
correct/add protection against snprintf overflow.

Make new function named tsc_is_invariant() to avoid code duplication.
The behavior of acpicpu_md_flags() will change on some CPUs because
the detecting code of invariant TSC is replaced with newer code.

Allow 4-bit range for MSR_THERM_CONTROL.

Modify some macros and add some new macros for CPU family and model
to reduce code duplication and to avoid bug.

CPUID_TO_STEPPING(cpuid) (not changed)

CPUID_TO_FAMILY(cpuid) (new)
CPUID_TO_MODEL(cpuid) (new)

Return the display family and the display model.
The macro names are the same as FreeBSD.

CPUID_TO_BASEFAMILY(cpuid) (The old name was CPUID2FAMILY)
CPUID_TO_BASEMODEL(cpuid) (The old name was CPUID2MODEL)

Only for the base field.

CPUID_TO_EXTFAMILY(cpuid) (The old name was CPUID2EXTFAMILY)
CPUID_TO_EXTMODEL(cpuid) (The old name was CPUID2EXTMODEL)

Only for the extended field.

See http://mail-index.netbsd.org/port-amd64/2013/11/12/msg001978.html

branches: 1.72.2;
Disable C1E also on K8, if present. From Imre Vadasz <imre@vdsz.com>
in PR install/47224.

branches: 1.71.2; 1.71.6; 1.71.8;
Fix missing case for AMD 0x15.

Add non-XPSS support for AMD family 15h a.k.a. "Bulldozer". Ok releng@.

branches: 1.69.4;
Add support for AMD family 12h. Also revert revision 1.67, as it implies
maintenance burden for limited value. XXX: Need to add family 15h too.

branches: 1.68.2;
Convert to use cpufreq(9).

Try to obtain reliable MHz values for AMD familiesi 10h and 11h.

Be more intelligent; read the MSR_CMPHALT with rdmsr_safe() and set the
C1E-flag based on this. Pointed out by jmcneill@.

As the detection of C1E is not entirely clear-cut, use rdmsr_safe()
when reading the AMD "interrupt pending and CMP-halt register".

Do not disable interrupts at machine-level in the MI idle-loop entry.

Fix bug pointed out by njoly@.

Get rid of RUN_ONCE(9). Should fix PR # kern/44043.

Move the evaluation of the _PDC control method out from the acpicpu(4)
driver to the main acpi(4) stack. Follow Linux and evaluate it early.
Should fix PR port-amd64/42895, possibly also PR kern/42583, and many
other comparable bugs.

A common sense explanation is that Intel supplies additional CPU tables to
OEMs. BIOS writers do not bother to modify their DSDTs, but instead load
these extra tables dynamically as secondary SSDT tables. The actual Load()
happens when the _PDC method is invoked, and thus namespace errors occur
when the CPU-specific ACPI methods are not yet present but referenced in the
AML by various drivers, including, but not limited to, acpitz(4).

When getting the frequency, use APERF/MPERF as a fallback method.

branches: 1.59.2;
Remove the sanity check that tested the internal consistency of the "FID/VID
algorithm" used by K8. Tested by cegger@. The check is still included in the
original powernow(4) (where possible failures have probably gone unnoticed
because the driver is less noisy).

Neither pci_dma64_available(), pci_probe_device(), pci_mapreg_map(9),
pci_find_rom(), pci_intr_map(9), pci_enumerate_bus(), nor the match
predicate passed to pciide_compat_intr_establish() should ever modify
their pci_attach_args argument, so make their pci_attach_args arguments
const and deal with the fallout throughout the kernel.

For the most part, these changes add a 'const' where there was no
'const' before, however, some drivers and MD code used to modify
pci_attach_args. Now those drivers either copy their pci_attach_args
and modify the copy, or refrain from modifying pci_attach_args:

Xen: according to Manuel Bouyer, writing to pci_attach_args in
pci_intr_map() was a leftover from Xen 2. Probably a bug. I
stopped writing it. I have not tested this change.

siside(4): sis_hostbr_match() needlessly wrote to pci_attach_args.
Probably a bug. I use a temporary variable. I have not tested this
change.

slide(4): sl82c105_chip_map() overwrote the caller's pci_attach_args.
Probably a bug. Use a local pci_attach_args. I have not tested
this change.

viaide(4): via_sata_chip_map() and via_sata_chip_map_new() overwrote the
caller's pci_attach_args. Probably a bug. Make a local copy of the
caller's pci_attach_args and modify the copy. I have not tested
this change.

While I'm here, make pci_mapreg_submap() static.

With these changes in place, I have tested the compilation of these
kernels:

alpha GENERIC
amd64 GENERIC XEN3_DOM0
arc GENERIC
atari HADES MILAN-PCIIDE
bebox GENERIC
cats GENERIC
cobalt GENERIC
evbarm-eb NSLU2
evbarm-el ADI_BRH ARMADILLO9 CP3100 GEMINI GEMINI_MASTER GEMINI_SLAVE GUMSTIX
HDL_G IMX31LITE INTEGRATOR IQ31244 IQ80310 IQ80321 IXDP425 IXM1200
KUROBOX_PRO LUBBOCK MARVELL_NAS NAPPI SHEEVAPLUG SMDK2800 TEAMASA_NPWR
TEAMASA_NPWR_FC TS7200 TWINTAIL ZAO425
evbmips-el AP30 DBAU1500 DBAU1550 MALTA MERAKI MTX-1 OMSAL400 RB153 WGT624V3
evbmips64-el XLSATX
evbppc EV64260 MPC8536DS MPC8548CDS OPENBLOCKS200 OPENBLOCKS266
OPENBLOCKS266_OPT P2020RDB PMPPC RB800 WALNUT
hp700 GENERIC
i386 ALL XEN3_DOM0 XEN3_DOMU
ibmnws GENERIC
macppc GENERIC
mvmeppc GENERIC
netwinder GENERIC
ofppc GENERIC
prep GENERIC
sandpoint GENERIC
sgimips GENERIC32_IP2x
sparc GENERIC_SUN4U KRUPS
sparc64 GENERIC

As of Sun Apr 3 15:26:26 CDT 2011, I could not compile these kernels
with or without my patches in place:

### evbmips-el GDIUM

nbmake: nbmake: don't know how to make /home/dyoung/pristine-nbsd/src/sys/arch/mips/mips/softintr.c. Stop

### evbarm-el MPCSA_GENERIC
src/sys/arch/evbarm/conf/MPCSA_GENERIC:318: ds1672rtc*: unknown device `ds1672rtc'

### ia64 GENERIC

/tmp/genassym.28085/assym.c: In function 'f111':
/tmp/genassym.28085/assym.c:67: error: invalid application of 'sizeof' to incomplete type 'struct pcb'
/tmp/genassym.28085/assym.c:76: error: dereferencing pointer to incomplete type

### sgimips GENERIC32_IP3x

crmfb.o: In function `crmfb_attach':
crmfb.c:(.text+0x2304): undefined reference to `ddc_read_edid'
crmfb.c:(.text+0x2304): relocation truncated to fit: R_MIPS_26 against `ddc_read_edid'
crmfb.c:(.text+0x234c): undefined reference to `edid_parse'
crmfb.c:(.text+0x234c): relocation truncated to fit: R_MIPS_26 against `edid_parse'
crmfb.c:(.text+0x2354): undefined reference to `edid_print'
crmfb.c:(.text+0x2354): relocation truncated to fit: R_MIPS_26 against `edid_print'

Reset APERF and MPERF only after interrupts have been enabled.

Remove the "simple CPU lock" that was unnecessary.
Thanks to rmind@ for clarifications.

branches: 1.55.2;
Add __cpu_simple_lock_t. Use it, x86_read_psl(), and x86_disable_intr() to
disable interrupts locally and protect the access to APERF and MPERF. Also
rationalize the MD initialization sequence.

If the P-state control mask is set, do a proper read-modify-write.

Rename a badly named constant. Make it correspond with <x86/specialreg.h>.

Adjust the detection of Turbo Boost to prevent a theoretical array OOB access.

Append Intel's Turbo Boost to the debug printfs if we detect it.

Remove the cross-call from the APERF/MPERF -function.

Move the xcall(9) that does the P- and T-state transformations from the MD
layer to the main code. Makes the caches coherent and provides consistent
vmstat(1) output. This is still not quite right, given that most of the
cross-calls are typically unnecessary with the dependency coordination.

Provide MD wrappers for match and attach.

Claim to support the dependency coordination during the _PDC/_OSC query.
(Although we do not actually support it.) Only after these bits are set,
many Intel-based BIOSes are willing to relinquish the necessary information.

Fix an oversight; the APERF and MPERF counters are per-CPU, so also reset
these by broadcasting to all CPUs with x86_msr_xcall(9).

Add couple of comments.

Also declare support for APERF/MPERF during the BIOS _PDC/_OSC query.

Rename couple of badly named functions for consistency. No functional change.

Add support for APERF and MPERF on AMD processors.

Add preliminary support for the IA32_APERF and IA32_MPERF frequency counters.
These are not yet used for anything and only Intel is supported at the moment.

add support for Family 14h (AMD Fusion)

Fix and add comments.

branches: 1.38.2; 1.38.4;
Move the function that counts the CPUs from acpicpu(4) to the MD layer.

Add an additional assertion for the control MSR address.

Fix boolean brain freeze.

Add AMD C1E quirk. Tested by cegger@.

(a) This should be removed once C-states are supported.

(b) As there seems to be no reliable way to detect whether C1E is present,
the quirk blindly assumes that C1E is used on families 10h and 11h.

branches: 1.34.2;
Add definitions for Intel Digital Thermal Sensor and Power Management, at
CPUID Fn0000_0006, %eax, %ecx. Use these instead of magic numbers.

As all reported P-state failures so far have centered around the status-
check (today it was christos@' laptop), follow Linux and disable this rather
expensive sanity-check for the time being. A hypothesis about the cause of
the failures relates to the absence of cross-CPU coordination in the current
implementation.

Add native support for AMD family 0Fh processors. This is the furthest we
will go backwards; K7 will not be supported already due doubts about
availability and reliability of ACPI during that era. Some unfortunate code
duplication is present (but not overly much). Thanks to cegger@ and jakllsch@
for patiently testing this.

Other entry points beyond x86_cpu_idle_halt() may use HLT as the
idle-mechanism. Send an IPI also for these in cpu_need_resched().

Still DELAY(9) a little even when we do not do the status-check.

After discussion with jakllsch@ and jmcneill@, revert the previous and only
do the status-check when the comparison value reported by BIOS is not zero.
The uncertainty noted in the previous commit still applies. But if we ever
see a timeout again, it will likely be either a firmware bug or a special
case like the Intel Turbo Boost.

When we do the sanity check that a P- or T-state transition was successful,
compare also against the control-field. There appears to be many BIOSes in
the field that report a zero value in the status-field. It is unclear whether
this should be taken as a hint that the status-check is not necessary also
during P-state transitions. If we still see timeouts (EAGAIN), this should
be reverted and the status-check should be bypassed if ps->ps_status is 0.

Use an inverse logic when filling the (X)PSS structures -- if we know
the addresses, we trust ourselves more than a random BIOS in the field.

Add a comment.

Check from CPUID 0x06 %eax (on Intel) whether we might actually have an
invariant APIC timer or an "ARAT" ("always running APIC timer"). This means
that the APIC timer may keep ticking at the same rate also in deep C-states
with some new or forthcoming Intel CPUs.

Add a quirk for Turbo Boost.

It was observed that at least Sverre Froyen's ThinkPad T500 reports values
that do not match readings from the IA32_PERF_STATUS register. This only
applied to the P0-state. Thus, for now, skip the status check if Turbo
Boost has been detected and the requested state is P0.

This needs to be revisited once Turbo Boost actually works in NetBSD. It is
unclear whether this is a BIOS flaw or not; these values may well be what we
get from IA32_PERF_STATUS once the CPU actually uses the +133.33 MHz boost.

Detect Intel's Turbo Boost and presence of IA32_APERF/IA32_MPERF. The former
is required for a quirk, and the latter is needed for hardware P-state
coordination (once acpicpu(4) will support fine-grained coordination).

Detect whether TSC is invariant, which may be the case on both new AMD and
Intel processors. The invariance means that TSC runs at a constant rate
during all ACPI state changes. If it is variant, skew may occur and TSC is
generally unsuitable for wall clock services. This is especially relevant
with C-states; with variant TSC, the whole counter may be stopped with states
larger than C1. All x86 CPUs before circa mid-2000s can be assumed to have a
variant time stamp counter.

Properly detect AMD hardware P-state support. Also detect "core boost" (only
present in some models of family 10h).

Check if SpeedStep is enabled. If it is disabled, try to enable it.

Revert all previous changes that were made naively believing that the
existing CPU power management implementations could peacefully coexist with
the acpicpu(4) driver. The following options can not be used with acpicpu(4):
ENHANCED_SPEEDSTEP, INTEL_ONDEMAND_CLOCKMOD, POWERNOW_K7, and POWERNOW_K8.

Properly calculate the AMD CPU family.

Add native P-state support for AMD family 10h and 11h processors. Both are
supported irrespective of XPSS. Family 10h tested by jakllsch@.

VIA CPUs can have EST as well, so treat them the same as Intel

Use the idea from cegger@ and fill the (X)PSS structure during initialization.

Check the status of P- and T-state transformations on all CPUs. This is
still not ideal, as ACPI gives us information about "cross logical processor
dependencies". For instance, a single MSR call on one CPU may cause all other
CPUs in the same domain to follow the state shift. Thus, rather than using
xc_broadcast(9), we should xc_unicast(9) on per-domain or per-CPU-set basis.

Add MD support for the vendor-independent extended PSS. Some conforming AMD
systems are known to work. Alas, not all of them. We still need to deal with
the variety of different PowerNow! revisions.

branches: 1.12.2;
Move the PIIX4-quirk to the MD file and disable T-states for PIIX4.

Remove some unnecessary locking. Mainly a leftover from previous revisions
where the dynamic maximum/minimum was used also when retrieving the current
state. The state-array itself changes only in C-states.

Merge T-state a.k.a. throttling support for acpicpu(4).

Remarks:

1. Native instructions are supported only on Intel. Native support for
other x86 vendors will be investigated. By assumption, AMD and others
use the I/O based approach.

2. The existing code, INTEL_ONDEMAND_CLOCKMOD, must be disabled in
order to use acpicpu(4). Otherwise fatal MSR races may occur.
Unlike with P-states, no attempt is done to disable the existing
implementation.

3. There is no rationale to export controls to user land.

4. Throttling is an artefact from the past. T-states will not be used for
power management per se. For CPU frequency management, P-states are
preferred in all circumstances. No noticeable additional power savings
were observed in various experiments. When the system has been scaled
to the highest (i.e. lowest power) P-state, it is preferable to move
from C0 to deeper C-states than it is to actively throttle the CPU.

5. But T-states need to be implemented for passive cooling via acpitz(4).
As specified by ACPI and Intel documents, these can be used as the
last line of defence against critical thermal conditions. Support
for this will be added later.

branches: 1.9.2;
Revert the previous changes to EST. The used hack had an obvious flaw:
the acpicpu(4) driver should attach even if the existing frequency management
code fails to attach, mainly because ACPI is the only proper way to deal
with EST on new Intel system.

Use a more drastic hack to deal with this: when acpicpu(4) attachs, it tears
down any existing sysctl(8) controls and installs identical ones in place.
Upon detachment, the initialization function of the existing EST is called.

Remove a redundant function.

When retrieving the current frequency, scan all available P-states.
Only use the dynamic maximum when setting a frequency.

Move the sysctl function pointers used by acpicpu(4) to x86/cpu.c.
Rename these so that the same pointers may be used in other parts.

Merge P-state support for acpicpu(4).

Remarks:

1. All processors (x86 or not) for which the vendor has implemented
ACPI I/O access routines are supported. Native instructions are
currently supported only for Intel's "Enhanced Speedstep". Code for
"PowerNow!" (AMD) will be merged later. Native support for VIA's
"PowerSaver" will be investigated.

2. Backwards compatibility with existing userland code is maintained.
Comparable to the case with cpu_idle(9), the ACPI CPU driver
installs alternative functions for the existing sysctl(8) controls.
The "native" behavior (if any) is restored upon detachment.

3. The dynamic nature of ACPI-provided P-states needs more investigation.
The maximum frequency induced (but not forced) by the firmware may
change dynamically. Currently, the sysctl(8) controls error out with
a value larger than the dynamic maximum. The code itself does not
however yet react to the notifications from the firmware by changing
the frequencies in-place. Presumably the system administrator should
be able to choose whether to use dynamic or static frequencies.

Run a xcall(9) to ensure that all CPUs are out from the ACPI idle-loop
before detachment.

Make sure we use MWAIT with MONITOR.

Also clarify when we have interrupts disabled.

Add missing CVS identifiers.

Merge a driver for ACPI CPUs with basic support for processor power states,
also known as C-states. The code is modular and provides an easy way to add
the remaining functionality later (namely throttling and P-states).

Remarks:

1. Commented out in the GENERICs; more testing exposure is needed.

2. The C3-state is disabled for the time being because it turns off
timers, among them the local APIC timer. This may not be universally
true on all x86 processors; define ACPICPU_ENABLE_C3 to test.

3. The algorithm used to choose a power state may need tuning. When
evaluating the appropriate state, the implementation uses the
previous sleep time as an indicator. Additional hints would include
for example the system load.

Also bus master activity is evaluated when choosing a state. The
usb(4) stack is notorious for such activity even when unused.
Typically it must be disabled in order to reach the C3-state,
but it may also prevent the use of C2.

4. While no extensive empirical measurements have been carried out, the
power savings are somewhere between 1-2 W with C1 and C2, depending
on the processor, firmware, and load. With C3 even up to 4 W can be
saved. The less something ticks, the more power is saved.

ok jmcneill@, joerg@, and discussed with various people.

x86: Wire up PCI resource manager if enabled.

Enable in your kernel config with `options PCI_RESOURCE'.

Adapted from a patch by mlelstv@.

PR port-amd64/59118: Thinkpad T495s - iwm PCI BAR is zero

branches: 1.39.2;
Introduce pvh_boot boolean to identify the real hypervisor when booting in PVH
mode.

As of now, sys/arch/x86/x86/identcpu.c / identify_hypervisor() returns in the
case of vm_guest being VM_GUEST_GENPVH, yet this VM type is not an actual
hypervisor but an information recorded in locore.S to drive boot method.
We need to investigate what type of hypervisor is really running the VM in
order to apply specifics, so instead of relying on vm_guest_is_pvh() which only
checks for VM_GUEST_XENPVH || VM_GUEST_GENPVH, pvh_boot informs on the boot
method while allowing to identify the real hypervisor.

Idea ok'd by bouyer@, tested on Xen domU, Xen dom0 with GENERIC PVH and
qemu GENERIC PVH boot.

Introduce vm_guest_is_pvh() and use it in place of
(vm_guest == VM_GUEST_XENPVH || vm_guest == VM_GUEST_GENPVH)

Add support for non-Xen PVH guests to amd64. Patch from
Emile 'iMil' Heitor in PR kern/57813, with some cosmetic tweaks by me.
Tested on bare metal, Xen PV and Xen PVH by me.

branches: 1.36.6;
Declare
int acpi_md_vesa_modenum;
int acpi_md_vbios_reset;
struct vcons_screen x86_genfb_console_screen;

in genfb_machdep.h instead of locally as extern in various .c files.

x86/acpi/acpi_machdep.c: Nix trailing whitespace.

No functional change intended.

branches: 1.34.2;
x86/acpi: Mark acpica interrupt handlers MP-safe.

acpica has its own internal locking, and the interrupt handlers we
install with AcpiInstall*Handler (gpe, notify, &c.) also have their
own locking.

x86: Split most of pmap.h into pmap_private.h or vmparam.h.

This way pmap.h only contains the MD definition of the MI pmap(9)
API, which loads of things in the kernel rely on, so changing x86
pmap internals no longer requires recompiling the entire kernel every
time.

Callers needing these internals must now use machine/pmap_private.h.
Note: This is not x86/pmap_private.h because it contains three parts:

1. CPU-specific (different for i386/amd64) definitions used by...

2. common definitions, including Xenisms like xpmap_ptetomach,
further used by...

3. more CPU-specific inlines for pmap_pte_* operations

So {amd64,i386}/pmap_private.h defines 1, includes x86/pmap_private.h
for 2, and then defines 3. Maybe we should split that out into a new
pmap_pte.h to reduce this trouble.

No functional change intended, other than that some .c files must
include machine/pmap_private.h when previously uvm/uvm_pmap.h
polluted the namespace with pmap internals.

Note: This migrates part of i386/pmap.h into i386/vmparam.h --
specifically the parts that are needed for several constants defined
in vmparam.h:

VM_MAXUSER_ADDRESS
VM_MAX_ADDRESS
VM_MAX_KERNEL_ADDRESS
VM_MIN_KERNEL_ADDRESS

Since i386 needs PDP_SIZE in vmparam.h, I added it there on amd64
too, just to keep things parallel.

- Define a device call for PCI bus instances to fetch a direct child's
device handle given the device's device/function #s (extracted from
a pcitag_t). Use it to associate the handle with the child device
at config_found() time.
- Implement this device call for ACPI and OpenFirmware.
- Enable the OpenFirmware variant for evbarm FDT, macppc, ofppc, sparc64.
- Obsolete acpi_device_register(); it is no longer needed.
- Obsolete setting the OpenFirmware handle in PCI devices in the
sparc64 device_register(); it is no longer needed.

branches: 1.31.4; 1.31.6;
Call acpi_device_register() as appropriate.

branches: 1.30.2;
Introduce Xen PVH support in GENERIC.
This is compiled in with
options XENPVHVM
x86 changes:
- add Xen section and xen pvh entry points to locore.S. Set vm_guest
to VM_GUEST_XENPVH in this entry point.
Most of the boot procedure (especially page table setup and switch to
paged mode) is shared with native.
- change some x86_delay() to delay_func(), which points to x86_delay() for
native/HVM, and xen_delay() for PVH

Xen changes:
- remove Xen bits from init_x86_64_ksyms() and init386_ksyms()
and move to xen_init_ksyms(), used for both PV and PVH
- set ISA no-legacy-devices property for PVH
- factor out code from Xen's cpu_bootconf() to xen_bootconf()
in xen_machdep.c
- set up a specific pvh_consinit() which starts with printk()
(which uses a simple hypercall that is available early) and switch to
xencons when we can use pmap_kenter_pa().

Add acpi_intr_mask() and acpi_intr_unmask() which, following the pre-existing
ACPI software layering model, are wrappers around acpi_md_intr_mask() and
acpi_md_intr_unmask(), which in turn are wrappers around intr_mask() and
intr_unmask().

XXX ARM and IA64 implementations of acpi_md_intr_mask() and
acpi_md_intr_unmask() are just stubs for now.

Cast physical addresses via uintptr_t to ACPI_PHYSICAL_ADDRESS to deal
with all size variants of the types used here in different builds.
Patch from manu@.

Attempt to obtain ACPI RSDP from the hypervisor for Xen PV

There are three possible way of obtaining the ACPI RSDP
- From Extended BIOS Data Area (EBDA) when kernel or Xen was booted from
BIOS bootstrap
- From EFI SystemTable when kernel is booted from EFI bootstrap
- When Xen is booted from EFI bootstrap, EBDA is not mapped, and EFI
SystemTable is not passed to the kernel. The only way to go is to
obtain ACPI RSDP trhough an hypercall.

Note: EFI bootstrap support for booting Xen has not yet been committed.

branches: 1.26.2;
Handle ISA/EISA interrupts like isa_machdep.c.

In acpi_md_OsRemoveInterruptHandler() redir and mpflags are only
relevant to the NIOAPIC > 0 case (not used without that). Rearrange
#if's slightly to make that happen (avoid "set but not used" warnings
(aka errors) when NIOAPIC == 0 (or undefined)).

Start replacing the x86 PTE bits.

Fix bug, PG_W is 'wired', not 'writable'.

We reorganise definitions for XEN source support as follows:

XEN - common sources required for baseline XEN support.
XENPV - sources required for support of XEN in PV mode.
XENPVHVM - sources required for support for XEN in HVM mode.
XENPVH - sources required for support for XEN in PVH mode.

Apply MADT interrupt source overrides to interrupts established via
acpi_md_intr_establish.

Add MD functions for establishing and disestablishing interrupt handlers.

branches: 1.19.2;
Allow registering ACPI interrupt handlers with a xname.
AcpiOsInstallInterruptHandler(), part of ACPICA API, doesn't allow passing
the xname. I extend the API with AcpiOsInstallInterruptHandler_xname()
for this purpose, and change acpi_md_OsInstallInterruptHandler() to
accept and use the xname (ia64 doens't use it).
The xname was hardcoded to "acpi SCI" in the
x86 acpi_md_OsInstallInterruptHandler(), so I make
AcpiOsInstallInterruptHandler() call
AcpiOsInstallInterruptHandler_xname with xname = "acpi SCI".

Now 'vmstat -i' shows the device's name instead of "acpi SCI" for for i2c HID
interrupts.

Proposed on tech-kern@ on Dec 29.

branches: 1.18.6; 1.18.12;
Handle persistent memory. Currently only debug output.

x86: make btinfo_memmap from btinfo_efimemmap for to reduce mem_cluster_cnt.

should fix PR/51953.

efi_md::md_virt always uses uint64_t.

Initial commit of native amd64 EFI boot loader.

branches: 1.14.2;
provide intr xname

Set hw.acpi.sleep.vbios when a non-HW accelerated VGA driver attaches.
If the VGA_POST option is present in the kernel the default value is 2,
otherwise 1. PR kern/50781

Reviewed by: agc, mrg

branches: 1.12.2;
Fix build break.

Add support for grub to find the ACPI root table pointer via a bootinfo entry
from grub.
From: https://mail-index.netbsd.org/tech-kern/2014/05/22/msg017119.html

CID/1325751: Avoid possible 32 bit overflow.

PCI Extended Configuration stuff written by nonaka@:
- Add PCI Extended Configuration Space support into x86.
- Check register offset of pci_conf_read() in MD part. It returns (pcireg_t)-1
if it isn't accessible.
- Decode Extended Capability in PCI Extended Configuration Space.
Currently the following extended capabilities are decoded:
- Advanced Error Reporting
- Virtual Channel
- Device Serial Number
- Power Budgeting
- Root Complex Link Declaration
- Root Complex Event Collector Association
- Access Control Services
- Alternative Routing-ID Interpretation
- Address Translation Services
- Single Root IO Virtualization
- Page Request
- TPH Requester
- Latency Tolerance Reporting
- Secondary PCI Express
- Process Address Space ID
- LN Requester
- L1 PM Substates
The following extended capabilities are not decoded yet:
- Root Complex Internal Link Control
- Multi-Function Virtual Channel
- RCRB Header
- Vendor Unique
- Configuration Access Correction
- Multiple Root IO Virtualization
- Multicast
- Resizable BAR
- Dynamic Power Allocation
- Protocol Multiplexing
- Downstream Port Containment
- Precision Time Management
- M-PCIe
- Function Reading Status Queueing
- Readiness Time Reporting
- Designated Vendor-Specific

branches: 1.8.4;
acpi_md_findoverride is only used when NIOAPIC > 0, so don't provide it
otherwise.

branches: 1.7.2;
Correct acpi_md_OsWritable() logic so that it can return TRUE.
From Masanori Kanaoka in PR 47571.

branches: 1.6.4;
yet more fixes for PR 47648 / PR 47016:
when using a temporary mp_intr_map, initialize the "flags" field
as well as "redir" since apic_set_redir() uses both. fix how
the flags field is change when applying an override, the trigger
and polarity sub-fields aren't just one bit like they are in redir.

redo the ACPI interrupt handler setup again, this time handling
MADT overrides that change the pin as well as the polarity.
fixes PR 47648.

locate PCI buses and determine their bus numbers using the info
previously extracted from ACPICA rather than trying to figure it out again.
allow PCI buses that don't have a _PRT method.

branches: 1.3.2; 1.3.6;
acpi_md_ncpus: use kcpuset_attached instead.

branches: 1.2.2; 1.2.4; 1.2.8;
#include <sys/bus.h> instead of <machine/bus.h>.

branches: 1.1.2;
Follow IA-64 with the x86-specific ACPI MD functions and move these where
they belong to. Remove an unused function. Minor KNF. No functional change.

branches: 1.2.2; 1.2.4;
Use acpi_match_cpu_handle() from acpi_util.c and only evaluate
the _PDC control method for CPUs that are enabled in the MADT.

Move the evaluation of the _PDC control method out from the acpicpu(4)
driver to the main acpi(4) stack. Follow Linux and evaluate it early.
Should fix PR port-amd64/42895, possibly also PR kern/42583, and many
other comparable bugs.

A common sense explanation is that Intel supplies additional CPU tables to
OEMs. BIOS writers do not bother to modify their DSDTs, but instead load
these extra tables dynamically as secondary SSDT tables. The actual Load()
happens when the _PDC method is invoked, and thus namespace errors occur
when the CPU-specific ACPI methods are not yet present but referenced in the
AML by various drivers, including, but not limited to, acpitz(4).

Move definition of acpi_md_vesa_modenum to acpi_wakeup.c; allows building
kernels without framebuffer devices.
Problem reported by John D. Baker on current-users@

Declare
int acpi_md_vesa_modenum;
int acpi_md_vbios_reset;
struct vcons_screen x86_genfb_console_screen;

in genfb_machdep.h instead of locally as extern in various .c files.

xen: Provide definitions or ifdefs to make drm build in XEN3_DOM0.

No idea if it works, but it builds now.

PR port-xen/49330

branches: 1.54.12;
x86: Reset cached tsc in every lwp to 0 on suspend/resume.

This avoids spuriously warning about tsc going backwards, which is to
be expected after a suspend/resume cycle.

branches: 1.53.6;
- Recalibrate the APIC timer using the TSC, once the TSC has in turn been
recalibrated using the HPET. This gets the clock interrupt firing more
closely to HZ.

- Undo change with recent Xen merge and go back to starting the clocks in
initclocks() on the boot CPU, and in cpu_hatch() on secondary CPUs.

- On reflection don't use HPET delay any more, it works very well but means
going over the bus. It's enough to use HPET to calibrate the TSC and
APIC.

Tested on amd64 native, xen and xen PVH.

remove some unnecessary includes of internal UVM headers.

branches: 1.51.2;
Rewrite the FPU code on x86. This greatly simplifies the logic and removes
the dependency on IPL_HIGH. NVMM is updated accordingly. Posted on
port-amd64 a week ago.

Bump the kernel version to 9.99.16.

The second parameter to AcpiSetFirmwareWakingVector sets the
X_Firmware_Waking_Vector field (where supported), which will cause firmware
to resume in protected mode. Since our wake code assumes real mode, always
set X_Firmware_Waking_Vector to 0.

branches: 1.49.4;
Initialize the errata MSRs when waking up, otherwise they are clear and
we're re-enabling certain CPU bugs.

Reinitialize the PAT MSR when waking up, otherwise the write-combined
pages become write-through.

Remove unused macro

Save and restore xcr0 when doing ACPI sleeps. Should fix PR/49174.

branches: 1.45.8;
There is a huge fpu synchronization issue here.

When the remote CPUs receive the ACPI sleep IPI, they do not save the fpu
state of the lwp they are executing. The problem is, when waking up they
reinitialize the registers of their local fpu and go back to their lwp
directly. Therefore, if an lwp is interrupted while storing data in an fpu
register, that data gets overwritten, which basically means the lwp is
likely to go crazy when resuming execution.

Fix this by simply saving the fpu state correctly. This way when going to
sleep the state is stored in the lwp's pcb and CR0_TS is set, so the next
time the lwp wants to use the fpu we'll get a dna, and the state will be
restored as expected.

While here, don't forget to reenable interrupts (and the spl) if an error
occurs.

Reload the MSRs on the original cpu on i386 - looks like I forgot this part
in my rev1.41. Technically it does not change anything, since the only MSR
is NOX and it is already reloaded in the trampoline.

Don't include sys/cdefs.h and __KERNEL_RSCID twice... once is enough.

use a value of hw.acpi.sleep.vbios that might actually
work for any real hardware suspend.

stop dragging feet through the ground in PR kern/50781

Call cpu_init_msrs on i386 when waking up. Currently it does not change
anything, since MSR_EFER is already enabled earlier. But if we add new
MSRs in the future, we will want them when waking up as well.

The MSR EFER state is not saved and restored when sleeping on i386. On PAE,
the CPU crashes right after waking up, since it needs to access NOX-ed
pages, which are to be enabled in an MSR.

Fix this by properly saving and restoring the EFER MSR. It's a little
tricky since the wakeup code uses %edx, but rdmsr overwrites it. We just
save it in %esi.

Now, the CPU sleeps properly on PAE kernels.

branches: 1.39.2;
dup the argument of the wakeup vector. XXX: is that correct?

branches: 1.38.6;
Ensure that the top level sysctl nodes (kern, vfs, net, ...) exist before
the sysctl link sets are processed, and remove redundancy.

Shaves >13kB off of an amd64 GENERIC, not to mention >1k duplicate
lines of code.

Add explicit #include <x86/fpu.h> instead of relying on pcb.h including it.

Move sys/arch/amd64/amd64/fpu.c and sys/arch/amd64/include/fpu.h
into sys/arch/x86 in preparation for using the same code for i386.

Remove support for 'external' floating point units and the MS-DOS
compatible method of handling floating point exceptions.
Make kernel support for teh fpu non-optional (486SX should still work).
Only 386 cpus support external fpu, and i386 support was removed years ago.
This means that the npx code no longer uses port 0xf0 or interupt 13.
All the "npx at isa" lines go from the configs, arch/i386/isa/npx.c
is now mandatory for all i386 kernels.
I've renamed npxinit() to fpuinit() and npxinit_cpu() to fpuinit_cpu()
to match the very similar amd64 functions.
The fpu of the boot cpu is now initialised by a direct call from
cpu_configure(), this enables FP emulation for a 486SX.
(for amd64 the cr0 values are set in locore.S and similar).
This fixes a long-standing bug in linux_setregs() - which did not
save the fpu regsiters if they were active.
I've test booted a single cpu i386 kernel (using anita).
amd64 builds - none of teh changes should affect it.
The i386 XEN kernels build, but I'm not sure where they set cr0, and
it might have got lost!

revert fpu/pcu changes until we figure out what's wrong; they cause random
freezes

Use the MI "pcu" framework for bookkeeping of npx/fpu states on x86.
This reduces the amount of MD code enormously, and makes it easier
to implement support for newer CPU features which require more fpu
state, or for fpu usage by the kernel.
For access to FPU state across CPUs, an xcall kthread is used now
rather than a dedicated IPI.
No user visible changes intended.

branches: 1.32.2; 1.32.4;
It turns out we're actually waiting for other processors to be unbusy, not busy.
Unbreaks ACPI suspend on uniprocessor. Probably fixes unnoticed bugs on MP.
Needs pullup to netbsd-6.

- Convert x86 MD code, mainly pmap(9) e.g. TLB shootdown code, to use
kcpuset(9) and thus replace hardcoded CPU bitmasks. This removes the
limitation of maximum CPUs.

- Support up to 256 CPUs on amd64 architecture by default.

Bug fixes, improvements, completion of Xen part and testing on 64-core
AMD Opteron(tm) Processor 6282 SE (also, as Xen HVM domU with 128 CPUs)
by Manuel Bouyer.

Now that 6.0 is branched, remove the ACPI-related sysctl nodes in machdep.

branches: 1.29.2; 1.29.6; 1.29.8;
#include <sys/bus.h> instead of <machine/bus.h>.

Explicitly re-enable the SCI interrupt when the wakeup starts (and before
interrupts are enabled). A workaround for a BIOS bug. Fixes the interrupt
storm reported by Taylor R. Campbell in PR # 44581.

branches: 1.27.2; 1.27.4;
Add a comment.

Move the ACPI sleep-specific sysctl variables to hw.acpi.sleep. The old
machdep-variables are provided for backwards compatibility (eventually these
should be removed). All ACPI sysctl variables are now under hw.acpi.

Remove the custom enter_s4_with_bios(). Use ACPICA's native
AcpiEnterSleepStateS4bios() instead. Minimum functional change.

ok jmcneill@

Use acpi_eval_set_integer(), KNF. No functional change.

UINT32 -> uint32_t; UINT8 -> uint8_t.

Use CTLTYPE_BOOL.

branches: 1.21.2;
Use native functions instead of polluting the namespace with ACPICA-macros.

branches: 1.20.2;
Add a flags argument to pmap_kenter_pa(9).
Patch showed on tech-kern@ http://mail-index.netbsd.org/tech-kern/2009/11/04/msg006434.html
No objections.

kill extra whitespaces
reviewed by tsutsui@

Be a bit more noisy by telling the user VGA_POST is missing in the
kernel config when trying machdep.acpi_vbios_reset=2.

Don't allow machdep.acpi_vbios_reset=2 if option VGA_POST is missing.

Pass the VBE mode number from the bootloader to the kernel, and then
make the ACPI wakecode aware of it. Restore the desired VBE mode on resume
when acpi_vbios_reset=1, so suspend/resume with genfb console will work.

Switch to ACPICA 20090730, and update for API changes.

Rearrange TSC inter-CPU synchronization code so that the gory details
are dealt with in x86/tsc.c and callers don't have to care that much.
Also add some comments and make some variables static.
approved by ad (a while ago)

bcopy -> memcpy

sync TSC on resume (because CPUs were switched off in the meantime),
otherwise we get diverging timecounters leading to eg the monotonic
clock jump backwards
(pullup candidate)

branches: 1.11.4;
On resum-from-RAM explicitly restore PCI link device state before
reenabling interrupts. At least one BIOS doesn't do this automatically
as reported by Christoph Egger.

branches: 1.10.2; 1.10.4;
Explicitly disable all GPEs and clear fixed events before enabling
interrupts. This is the first part of PR 38683.

Revert previous.

PR# 38683 - T61 cannot suspend with recent kernels

Don't restore spl until after AcpiLeaveSleepState.

machdep.acpi_vbios_reset = 2 --> vga_pci_resume will use x86emu to do a
POST when options VGA_POST is present.

branches: 1.6.4;
Share cpu.h between the x86 ports.

branches: 1.5.2;
Remove clause 3 and 4 from TNF licenses

branches: 1.4.2; 1.4.4;
Disable machdep.acpi_beep_on_reset by default.

branches: 1.3.6;
splhigh == splipi

branches: 1.2.2;
Introduce optional cpu_offline_md to execute MD actions at the end of
cpu_offline. Use this on amd64/i386 to force a FPU save. As this was
triggered by npxsave_cpu/fpusave_cpu not working for a different CPU,
remove the cpu_info argument and adjust npxsave_*/fpusave_* to use bool
for the save.

OK ad@

branches: 1.1.2; 1.1.4; 1.1.6; 1.1.8;
Add new IPI for saving CPU state explicitly, share high-level part of
ACPI wakeup code and teach it how to start the APs again. As a side
effect the CPU_START interface allows choosing between different
bootstrap codes more easily now.

Use sed, awk and hexdump from tools to make this work on Solaris. Ok by apb.

branches: 1.2.6; 1.2.8; 1.2.18; 1.2.26; 1.2.28;
How did these get lost?

branches: 1.1.2; 1.1.8; 1.1.10; 1.1.12;
file genwakecode.sh was initially added on branch jmcneill-pm.