Add ci_cpuid_level and ci_vendor holding the per-CPU basic cpuid
level and a numeric mapping of the cpu vendor, both from CPUID(0).
Convert the general use of strcmp(cpu_vendor) to simple numeric
tests of ci_vendor. Track the minimum of all ci_cpuid_level in the
cpuid_level global and continue to use that for what we vmm exposes.

AMD testing help matthieu@ krw@
ok miod@ deraadt@ cheloha@

Mtrr stops being a pseudo-device. We need to probe the cpu type and
initialize the structures when we see the first cpu. We also need to
initialize each cpu's properly (for PAT) before we setup mtrr on that
cpu. On i386 (late hatch) we were getting this desperately wrong on
the primary cpu.

After suspend/resume, we also need to do the same work. re-initialize
PAT before mtrr. On some laptops apparently PAT was not turned on by the
BIOS, so we ended up with incorrect setup for the primary cpu. Oops.

This makes mplayer on the x201 (and similar) machines work without weird
pauses after a suspend/resume. Many other things are likely fixed.
ok kettenis

Cleanup amd64 and i386 MTRR code -

1. Makes amd64 and i386 MTRR code nearly identical
2. Removes support for per-process MTRRs (which were never implemented)
3. Treat "unknown" MTRR types as uncacheable instead of trying to preserve
bogus settings made by the BIOS
4. Various KNF cleanups

Should be no functional change.

ok jsg@, deraadt@

Fix the order of checking if a machine has MTRR. We need to check
against the vendor string, then cpu family, then if the cpu claims to
have it.

requested by toby@

Also match against Via's cpu string to enable MTRR on matthieu@'s VIA Nano

compile tested on i386 by wcmaier@

Synchronize the MTRR API with i386, and enable

"just commit it" deraadt@

Mtrr stops being a pseudo-device. We need to probe the cpu type and
initialize the structures when we see the first cpu. We also need to
initialize each cpu's properly (for PAT) before we setup mtrr on that
cpu. On i386 (late hatch) we were getting this desperately wrong on
the primary cpu.

After suspend/resume, we also need to do the same work. re-initialize
PAT before mtrr. On some laptops apparently PAT was not turned on by the
BIOS, so we ended up with incorrect setup for the primary cpu. Oops.

This makes mplayer on the x201 (and similar) machines work without weird
pauses after a suspend/resume. Many other things are likely fixed.
ok kettenis

Cleanup amd64 and i386 MTRR code -

1. Makes amd64 and i386 MTRR code nearly identical
2. Removes support for per-process MTRRs (which were never implemented)
3. Treat "unknown" MTRR types as uncacheable instead of trying to preserve
bogus settings made by the BIOS
4. Various KNF cleanups

Should be no functional change.

ok jsg@, deraadt@

Fix the order of checking if a machine has MTRR. We need to check
against the vendor string, then cpu family, then if the cpu claims to
have it.

requested by toby@

Also match against Via's cpu string to enable MTRR on matthieu@'s VIA Nano

compile tested on i386 by wcmaier@

Synchronize the MTRR API with i386, and enable

"just commit it" deraadt@