Re: [PATCH] x86emul: V{,P}{COMPRESS,EXPAND}* can (wrongly) trigger assertion

On 16.07.2026 15:35, Teddy Astie wrote:
> Le 16/07/2026 à 12:45, Jan Beulich a écrit :
>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>> @@ -6236,9 +6236,11 @@ x86_emulate(
>>               ASSERT(op_bytes == n * elem_bytes);
>>               op_mask &= ~0ULL >> (64 - n);
>>               n = hweight64(op_mask);
>> -            op_bytes = n * elem_bytes;
>>               if ( n )
>> +            {
>> +                op_bytes = n * elem_bytes;
>>                   op_mask = ~0ULL >> (64 - n);
>> +            }
>>           }
>>           goto simd_zmm;
>>   
>>
> 
> That looks like a bit of a hack in my understanding.

It may be looked at it this way, yes. The entire file may be looked at this way,
really.

> Is there anything specific preventing the common SIMD logic from 
> accepting op_bytes being 0 ? Otherwise, we risk seeing similar issues 
> with other instructions (future or current).

Requiring op_bytes to be non-zero is a safe-guard. If any of the cases engaging
common SIMD emulation would fail to set this up correctly, it would be noticed
only if the path was actually taken (to serve a VM, or in the test or fuzzing
harnesses) and if results were checked to be correct. The test harness can't
reasonably guarantee all paths to be taken. Whereas the running fuzzing harness
doesn't prove that execution was actually correct; it only proves that we
didn't crash or hang. Skipping a memory access where one would be needed would
likely go entirely unnoticed there.

Jan