tree 85198d90bf62b36c5570cadb3c248d003b1e01e1
parent 2e284502288b705d1878a0aac29720b6d6e15fb8
author Jan Beulich <jbeulich@suse.com> 1749796832 +0200
committer Jan Beulich <jbeulich@suse.com> 1749796832 +0200

x86: refine UD<n> kind-of-insns

While documentation of these continues to be lacking sufficient detail,
it is becoming increasingly clear that in 66f1eba0b7e8 ("x86: correct
UDn") I went too far with requiring operands, to populate a ModR/M byte.
AMD hardware appears to always behave as indicated as "may" in PM 3.36,
which for all practical purposes means there's no ModR/M byte. The SDM
(rev 087) indicates that such behavior can occur on older hardware for
UD0. Re-add an operand-less UD1 form (as well as its UD2B alias), while
newly adding such a form also for UD0. Because of the ambiguity, there's
no good/easy way of handling both possibilities in the disassembler,
which hence remains unaltered.

Further, from all information I'm able to gather, the 0F opcode space
was only introduced with the i286; bump the minimal hardware requirement
for all UD<n> accordingly.