Re: [PATCH] x86emul: Treat the vector of INT imm8 as unsigned

[Jan Beulich <jbeulich@xxxxxxxx>]

On 12.11.2026 11:31, Stephen Cheng wrote:
> On 12.11.2026 10:29, Jan Beulich wrote:
>> On 12.11.2026 08:23, Stephen Cheng wrote:
>>> The decoder sign-extends all 8-bit immediates (SrcImmByte). For INT
>>> imm8 the immediate is the vector, which is unsigned. So INT $0x80 to
>>> INT $0xff put a negative vector into the event (e.g. -128 for 0x80).
>>>
>>> hvm_inject_event() then fails its "vector == event->vector" assertion,
>>> and a debug Xen panics. An HVM guest can trigger this with the forced
>>> emulation prefix (hvm_fep).
>>>
>>> Cast the vector to uint8_t, as is already done for the port of IN/OUT
>>> and the operand of AAM/AAD.
>>
>> I'm afraid this isn't sufficient: At least x86_insn_immediate() is also
>> affected, and then also for the other insns you mention above plus quite
>> a few more (in particular uniformly for 0F, 0F3A and XOP08). I think
>> this needs sorting in x86_decode_onebyte() for all of the former (some
>> of which I then need to mirror into the APX series for Map4), and in the
>> switch() below setting ctxt->opcode and s->desc (where decode_*() are
>> called) for the latter three.
>>
>> There'll then want to be a 2nd Fixes: tag for the commit which
>> introduced x86_insn_immediate().
> 
> Thanks Jan, I see. I'll move the fix into the decoder and add the 2nd
> Fixes: tag in v2.
> 
> Two questions:
> 
> 1. Which other one-byte insns do you mean by "quite a few more"? I can
>    see the shift/rotate counts (C0, C1). Are there others?

Having done the APX side change, it may indeed be just those in the base
opcode map. "quite a few" covered the other opcode maps which I did
mention.

> 2. Should I keep the existing (uint8_t) casts at the IN/OUT and AAM/AAD
>    use sites, or drop them?

I'd prefer if they were dropped in exchange.

Jan