qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC] alpha qemu arithmetic exceptions


From: Richard Henderson
Subject: Re: [Qemu-devel] [RFC] alpha qemu arithmetic exceptions
Date: Thu, 03 Jul 2014 21:30:05 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0

On 07/03/2014 05:50 PM, Al Viro wrote:
> OK, looks sane.  Next (trivial) bug: in translate_one()
>         case 0xF800:
>             /* WH64 */
>             /* No-op */
>             break;
> should be followed by
>         case 0xFC00:
>             /* WH64EN */
>             /* No-op */
>             break;

Huh.  I don't have any documentation for EV7.  Added.

> Another one is probably not worth bothering - PERR, CTPOP, CTLZ, UNPKBx and 
> PKxB
> don't accept literal argument.  For one thing, as(1) won't let you generate
> those, so it would have to be explicit
>       .long 0x70001620
> instead of
>       perr $0,0,$0
> On DS10 it gives SIGILL; under qemu it succeeds.  Trivial to fix, anyway,
> if we care about that (if (islit) goto invalid_opc; in 1C.030..1C.037).

Is it just 030..037, or everything under opcode 1C?

Sadly, V4 of the handbook doesn't mention *anything* about not actually
allowing literals for any of these insns.

For now, I've updated insns in the range you describe, because it's easy.

> CPU1: LDL_L reads 0
> CPU2: store 1
> ...
> CPU2: store 0
> CPU1: STL_C
> would have STL_C fail.  qemu implementation of those suckers will succeed.
> I'm not sure if anything in the kernel is sensitive to that, but analysis
> won't be fun...

I'm aware that lock/cond can be used in ways that we don't support, including
STL_C to a different address on the same cacheline as the LDL_L.

I'm also aware that if we actually did implement SMP, we would be vulnerable to
the ABA error you describe above.

That said, it's all moot until the PALcode grows actual SMP support for booting
and signalling secondary cpus.  Given that qemu implements SMP by multiplexing
the guest cpus on a single host thread, and so we can't actually speed up the
guest by implementing SMP, it's not seemed like a priority.

The next thing I'd work on given oodles of time is to add block device support
to the PALcode, so that the console could boot from disk like a real machine.
In theory, most of this code can be stolen from SeaBIOS.


r~



reply via email to

[Prev in Thread] Current Thread [Next in Thread]