x86/HPET: don't disable interrupt delivery right after setting it up

We shouldn't clear HPET_TN_FSB right after we (indirectly, via
request_irq()) enabled it for the channels we intend to use for
broadcasts.

This fixes a regression introduced by c/s 25103:0b0e42dc4f0a.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
x86/IRQ: fix valid-old-vector checks in __assign_irq_vector()

There are two greater-than-zero checks for the old vector retrieved,
which don't work when a negative value got stashed into the respective
arch_irq_desc field. The effect of this was that for interrupts that
are intended to get their affinity adjusted the first time before the
first interrupt occurs, the affinity change would fail, because the
original vector assignment would have caused the move_in_progress flag
to get set (which causes subsequent re-assignments to fail until it
gets cleared, which only happens from the ->ack() actor, i.e. when an
interrupt actually occurred).

This addresses a problem introduced in c/s 23816:7f357e1ef60a (by
changing IRQ_VECTOR_UNASSIGNED from 0 to -1).

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
x86/HPET: don't needlessly set up channels for broadcast

When there are more FSB delivery capable HPET channels than CPU cores
(or threads), we can simply use a dedicated channel per CPU. This
avoids wasting the resources to handle the excess channels (including
the pointless triggering of the respective interrupt on each
wraparound) as well as the ping-pong of the interrupts' affinities
(when getting assigned to different CPUs).

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
x86: remove further code applicable to 32-bit CPUs only

On the AMD side, anything prior to family 0xf can now be ignored, as
well as very low model numbers of family 6 on the Intel side.

Apart from that, there were several made up CPU features that turned
out entirely unused throughout the tree.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
x86/ucode: fix Intel case of resume handling on boot CPU

Checking the stored version doesn't tell us anything about the need to
apply the update (during resume, what is stored doesn't necessarily
match what is loaded).

Note that the check can be removed altogether because once switched to
use what was read from the CPU (uci->cpu_sig.rev, as used in the
subsequent pr_debug()), it would become redundant with the checks that
lead to microcode_update_match() returning the indication that an
update should be applied.

Note further that this was not an issue on APs since they start with
uci->mc.mc_intel being NULL.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Ben Guthro <ben@guthro.net>
Acked-by: Keir Fraser <keir@xen.org>
Revert 25960:6bf8b882df8f (x86: default-disable MWAIT-based idle driver ...)

The problem this was working around should be resolved with c/s
25961:6a5812129094 (x86/HPET: don't disable interrupt delivery right
after setting it up).
x86: replace literal numbers

In various cases, 256 was being used instead of NR_VECTORS or a derived
ARRAY_SIZE() expression. In one case (guest_has_trap_callback()), a
wrong (unrelated) constant was used instead of NR_VECTORS.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>