Re: [BUG] x86emul/test: avoid assertion in emul_test_read_xcr() when XSAVE is absent

On 20.08.2026 14:30, Andrew Precious wrote:
> I just realized that I attached the binary result without the fuzzer error.
> To generate the previous assertion error I would have to rerun the fuzzer
> again which took many hours(~18hrs). Though that was the only error I found
> after that long.
> 
> VM machine that I performed the fuzzing on:
> - A VM running Debian GNU/Linux 13 (trixie)
> - x86_64,QEMU Virtual CPU version 2.5

What does that mean CPUID-wise, seeing that ...

> On Thu, Aug 20, 2026 at 11:45 AM Jan Beulich <[email protected]> wrote:
>> On 19.08.2026 20:07, Andrew Mbugua wrote:
>>> While running the x86_instruction_emulator fuzzer via AFL, I encountered
>> an assertion failure in the emul_test_read_xcr() function.
>>
>> Thanks for the report.
>>
>>> The fuzzer is able to generate a CPU state where cpu_has_xsave is false.
>>
>> I'm having trouble here: cpu_policy isn't populated from fuzzing input, and
>>
>> /* Intentionally checking OSXSAVE here. */
>> #define cpu_has_xsave     (cpu_policy.basic.raw[1].c & (1u << 27))
>>
>> would mean that upon filling cpu_policy (emul_test_init() ->
>> x86_cpu_policy_fill_native()) the OSXSAVE bit would be clear. Are you
>> suggesting you did the fuzzing on some really old hardware?

... there was this aspect that I couldn't understand?

Jan