Rational behind partial AVX support in Qemu

Rational behind partial AVX support in Qemu

[Stevie Lavern]

[-- Attachment #1: Type: text/plain, Size: 1259 bytes --]

Hello,
I'm currently testing various binaries under qemu linux user and went into
a strange bug.

Here is the TLDR: is there a reason to allow VEX.L to be 1 when not
supporting AVX instructions? Crashing with illegal op may save some time
and headache to users.

And now for some context:
One of my test binaries had some AVX instructions and crashed in a weird
way.
As I understand AVX is not supported, and so a Qemu crash should be
expected.
However, in this instance, it's the guest that crashed, long after the
offending AVX instruction.

The faulty instruction was a `vmovups ymmword ptr [rsp], ymm0`.
Looking into i386/translate.c, it seems that it is correctly decoded but
its generation (see 'case 0x111' in `gen_sse`) is invalid.

Indeed, while the VEX prefix is correctly decoded, its VEX.L bit is never
used during the instruction generation and is always assumed to be 0.
Therefore, the instruction generated is a `vmovups xmmword ptr [rsp],
xmm0`, using a 128bits register instead of the orignal one using a 256bits
register.

My understanding is that the VEX prefix and 256 bits registers where
introduced by AVX. As Qemu does not support AVX, is there any kind of
reason not to crash (illegalop) when VEX.L = 1?

Best regards,

Thanks,
Stevie

[-- Attachment #2: Type: text/html, Size: 1551 bytes --]

Re: Rational behind partial AVX support in Qemu

[Richard Henderson]

On 1/5/22 9:09 AM, Stevie Lavern wrote:
> Hello,
> I'm currently testing various binaries under qemu linux user and went into a strange bug.
> 
> Here is the TLDR: is there a reason to allow VEX.L to be 1 when not supporting AVX 
> instructions?

There are some integer instructions that use vex encoding, e.g. andn, and we support some 
of those, thus any support for VEX at all.  But you're probably correct that we could 
usefully filter VEX.L = 1 early.


r~

Re: Rational behind partial AVX support in Qemu

[Stevie Lavern]

[-- Attachment #1: Type: text/plain, Size: 820 bytes --]

Hello,

Thanks for you answer!
I may put together a patch to crash if VEX.L is 1 (shouldn't be hard) and
submit it to the patch list.
Do you think it qualifies as "trivial patch" or should i go on with the
full patch submission process?


On Thu, Jan 6, 2022 at 3:45 AM Richard Henderson <
richard.henderson@linaro.org> wrote:

> On 1/5/22 9:09 AM, Stevie Lavern wrote:
> > Hello,
> > I'm currently testing various binaries under qemu linux user and went
> into a strange bug.
> >
> > Here is the TLDR: is there a reason to allow VEX.L to be 1 when not
> supporting AVX
> > instructions?
>
> There are some integer instructions that use vex encoding, e.g. andn, and
> we support some
> of those, thus any support for VEX at all.  But you're probably correct
> that we could
> usefully filter VEX.L = 1 early.
>
>
> r~
>

[-- Attachment #2: Type: text/html, Size: 1241 bytes --]

Re: Rational behind partial AVX support in Qemu

[Richard Henderson]

On 1/6/22 1:14 AM, Stevie Lavern wrote:
> Do you think it qualifies as "trivial patch" or should i go on with the full patch 
> submission process?

There is no "short" patch submission process.


r~

Re: Rational behind partial AVX support in Qemu

[Stevie Lavern]

[-- Attachment #1: Type: text/plain, Size: 524 bytes --]

Indeed, my bad, i was thinking about the "trivial patch" submission process.

For reference, the submitted patch can be found here
https://lists.nongnu.org/archive/html/qemu-devel/2022-01/msg00822.html

Thanks,
Stevie

On Thu, Jan 6, 2022 at 5:29 PM Richard Henderson <
richard.henderson@linaro.org> wrote:

> On 1/6/22 1:14 AM, Stevie Lavern wrote:
> > Do you think it qualifies as "trivial patch" or should i go on with the
> full patch
> > submission process?
>
> There is no "short" patch submission process.
>
>
> r~
>

[-- Attachment #2: Type: text/html, Size: 1015 bytes --]