On 23.04.2025 13:09, Jan Beulich wrote:
> On 23.04.2025 11:49, Andrew Cooper wrote:
>> On 23/04/2025 7:13 am, Jan Beulich wrote:
>>> @@ -5286,25 +5284,23 @@ x86_emulate(
>>> else if ( !dst.val )
>>> _regs.eflags |= X86_EFLAGS_ZF;
>>> }
>>> - else if ( zf )
>>> + else
>>> {
>>> - _regs.eflags |= X86_EFLAGS_ZF;
>>> - dst.type = OP_NONE;
>>> + emulate_2op_SrcV_srcmem("bsf", src, dst, _regs.eflags);
>>> + if ( _regs.eflags & X86_EFLAGS_ZF )
>>> + dst.type = OP_NONE;
>>
>> On Intel, BSF/BSR writes back the destination register. Notably, it
>> gets 0 extended per normal rules,
>
> That's also only on "older processors", as per the other footnote.
>
>> which is why you have to be extra
>> careful when using the trick of preloading it with -1; the result must
>> be interpreted as (int) even over a 64bit operation.
>>
>> This needs an amd_like() qualification to override dst.type. This
>> aspect genuinely is different between them. Alternatively, we might be
>> able to set the operand size always to 64 and write back the entire
>> register as the processor gave to us, but I'm not sure if that will have
>> effects elsewhere.
>
> Besides (as per above), amd_like() not covering all cases, this would
> then further need special treatment for 16-bit opsize. Plus promoting
> to 64-bit would require manually clipping the result to 5 bits when
> the original size wants 64-bit. That's imo far more complications
> than gains.
I guess I viewed this as more complicated than it is: We'd merely need
to zero-extend the source operand from opsize to 64 bits. The one
uncertainty there would be whether the undefined arithmetic flags
couldn't be dependent on operand size.
Tangential to this: Software having probed for the specific behavior of
the two insns (EFLAGS and/or destination register setting for a zero
source) will break when migrated. Therefore in principle we ought to
prevent such migrations. Thoughts there?
Jan
