All of lore.kernel.org
 help / color / mirror / Atom feed
* [Qemu-devel] [Bug 1810545] [NEW] [alpha] Strange exception address reported
@ 2019-01-04 18:21 Stefan Ring
  2019-01-04 19:05 ` [Qemu-devel] [Bug 1810545] " Peter Maydell
                   ` (4 more replies)
  0 siblings, 5 replies; 8+ messages in thread
From: Stefan Ring @ 2019-01-04 18:21 UTC (permalink / raw)
  To: qemu-devel

Public bug reported:

For some reason the SIGILL handler receives a different address under
qemu than it used to on real hardware. I don't know specifics about the
hardware used back then – it was some sort of 21264a somewhere between
600-800 MHz –, and I cannot say anything about the kernel as well, but I
know that it delivered the faulting address +4, while under qemu it
receives +8. I know because CACAO, an early Java JIT compiler extracts
the address from the SIGILL handler and inspects the code at the
faulting site, and it has substracted 4 from the handler address since
the dawn of time, and this used to produce the desired result on the
Alpha hardware. It actually ran on two different Alpha machines over the
years, and both behaved identically.

The handler looks like this:
void handler_sigill(int sig, siginfo_t *siginfo, void *_p)
{
  uintptr_t trap_address = (uintptr_t) (((ucontext_t*) _p)->uc_mcontext.sc_pc) - 4;
}

(paraphrasing, the actual code is here: https://bitbucket.org/cacaovm
/cacao-
staging/src/c8d3fbab864c3243f97629fcfa8d84ba71f38157/src/vm/jit/alpha/linux
/md-os.cpp?at=default&fileviewer=file-view-default#md-os.cpp-65)

I don't know much about the qemu source code and cannot say where this
is coming from at first glance. The gen_invalid function uses pc_next,
which sounds like the next instruction, not the next-to-next ;). In
theory it could actually be the kernel's fault, although I consider this
unlikely.

This is qemu-system-alpha with apparently the last Debian which existed
for Alpha (lenny). The kernel is 2.6.26-2-alpha-generic (Debian
2.6.26-29). Observed with qemu git 1b3e80082b, but I guess it is the
same with any version.

** Affects: qemu
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1810545

Title:
  [alpha] Strange exception address reported

Status in QEMU:
  New

Bug description:
  For some reason the SIGILL handler receives a different address under
  qemu than it used to on real hardware. I don't know specifics about
  the hardware used back then – it was some sort of 21264a somewhere
  between 600-800 MHz –, and I cannot say anything about the kernel as
  well, but I know that it delivered the faulting address +4, while
  under qemu it receives +8. I know because CACAO, an early Java JIT
  compiler extracts the address from the SIGILL handler and inspects the
  code at the faulting site, and it has substracted 4 from the handler
  address since the dawn of time, and this used to produce the desired
  result on the Alpha hardware. It actually ran on two different Alpha
  machines over the years, and both behaved identically.

  The handler looks like this:
  void handler_sigill(int sig, siginfo_t *siginfo, void *_p)
  {
    uintptr_t trap_address = (uintptr_t) (((ucontext_t*) _p)->uc_mcontext.sc_pc) - 4;
  }

  (paraphrasing, the actual code is here: https://bitbucket.org/cacaovm
  /cacao-
  staging/src/c8d3fbab864c3243f97629fcfa8d84ba71f38157/src/vm/jit/alpha/linux
  /md-os.cpp?at=default&fileviewer=file-view-default#md-os.cpp-65)

  I don't know much about the qemu source code and cannot say where this
  is coming from at first glance. The gen_invalid function uses pc_next,
  which sounds like the next instruction, not the next-to-next ;). In
  theory it could actually be the kernel's fault, although I consider
  this unlikely.

  This is qemu-system-alpha with apparently the last Debian which
  existed for Alpha (lenny). The kernel is 2.6.26-2-alpha-generic
  (Debian 2.6.26-29). Observed with qemu git 1b3e80082b, but I guess it
  is the same with any version.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1810545/+subscriptions

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Qemu-devel] [Bug 1810545] Re: [alpha] Strange exception address reported
  2019-01-04 18:21 [Qemu-devel] [Bug 1810545] [NEW] [alpha] Strange exception address reported Stefan Ring
@ 2019-01-04 19:05 ` Peter Maydell
  2019-01-07 17:57 ` Peter Maydell
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 8+ messages in thread
From: Peter Maydell @ 2019-01-04 19:05 UTC (permalink / raw)
  To: qemu-devel

Hmm, qemu-system-alpha ? The guest kernel should be doing the same thing
it would on real hardware -- I guess we're getting the value of the
exception address wrong when we deliver the exception to it.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1810545

Title:
  [alpha] Strange exception address reported

Status in QEMU:
  New

Bug description:
  For some reason the SIGILL handler receives a different address under
  qemu than it used to on real hardware. I don't know specifics about
  the hardware used back then – it was some sort of 21264a somewhere
  between 600-800 MHz –, and I cannot say anything about the kernel as
  well, but I know that it delivered the faulting address +4, while
  under qemu it receives +8. I know because CACAO, an early Java JIT
  compiler extracts the address from the SIGILL handler and inspects the
  code at the faulting site, and it has substracted 4 from the handler
  address since the dawn of time, and this used to produce the desired
  result on the Alpha hardware. It actually ran on two different Alpha
  machines over the years, and both behaved identically.

  The handler looks like this:
  void handler_sigill(int sig, siginfo_t *siginfo, void *_p)
  {
    uintptr_t trap_address = (uintptr_t) (((ucontext_t*) _p)->uc_mcontext.sc_pc) - 4;
  }

  (paraphrasing, the actual code is here: https://bitbucket.org/cacaovm
  /cacao-
  staging/src/c8d3fbab864c3243f97629fcfa8d84ba71f38157/src/vm/jit/alpha/linux
  /md-os.cpp?at=default&fileviewer=file-view-default#md-os.cpp-65)

  I don't know much about the qemu source code and cannot say where this
  is coming from at first glance. The gen_invalid function uses pc_next,
  which sounds like the next instruction, not the next-to-next ;). In
  theory it could actually be the kernel's fault, although I consider
  this unlikely.

  This is qemu-system-alpha with apparently the last Debian which
  existed for Alpha (lenny). The kernel is 2.6.26-2-alpha-generic
  (Debian 2.6.26-29). Observed with qemu git 1b3e80082b, but I guess it
  is the same with any version.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1810545/+subscriptions

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Qemu-devel] [Bug 1810545] Re: [alpha] Strange exception address reported
  2019-01-04 18:21 [Qemu-devel] [Bug 1810545] [NEW] [alpha] Strange exception address reported Stefan Ring
  2019-01-04 19:05 ` [Qemu-devel] [Bug 1810545] " Peter Maydell
@ 2019-01-07 17:57 ` Peter Maydell
  2019-01-07 19:00   ` Peter Maydell
  2019-01-08 11:47 ` Peter Maydell
                   ` (2 subsequent siblings)
  4 siblings, 1 reply; 8+ messages in thread
From: Peter Maydell @ 2019-01-07 17:57 UTC (permalink / raw)
  To: qemu-devel

The problem seems to be that the PC we report for an OPCDEC is first selected by gen_invalid()/gen-excp() in target/alpha/translate.c, which uses pc_next (ie the insn's address plus 4). But that is then handed through to our custom PALcode (https://git.qemu.org/?p=qemu-palcode.git;a=blob;f=pal.S;h=1781c4b415700ca3a68af07fdae90ae43e722501;hb=HEAD) which does
  addq    p6, 4, p1  // increment past the faulting insn
resulting in insn + 8.

That is, the palcode and the QEMU code have a disagreement about what
the (private) API between them is. I'm not sure which side is wrong and
should be corrected. I think the linux-user code assumes the same thing
that translate.c is doing, so perhaps the palcode.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1810545

Title:
  [alpha] Strange exception address reported

Status in QEMU:
  New

Bug description:
  For some reason the SIGILL handler receives a different address under
  qemu than it used to on real hardware. I don't know specifics about
  the hardware used back then – it was some sort of 21264a somewhere
  between 600-800 MHz –, and I cannot say anything about the kernel as
  well, but I know that it delivered the faulting address +4, while
  under qemu it receives +8. I know because CACAO, an early Java JIT
  compiler extracts the address from the SIGILL handler and inspects the
  code at the faulting site, and it has substracted 4 from the handler
  address since the dawn of time, and this used to produce the desired
  result on the Alpha hardware. It actually ran on two different Alpha
  machines over the years, and both behaved identically.

  The handler looks like this:
  void handler_sigill(int sig, siginfo_t *siginfo, void *_p)
  {
    uintptr_t trap_address = (uintptr_t) (((ucontext_t*) _p)->uc_mcontext.sc_pc) - 4;
  }

  (paraphrasing, the actual code is here: https://bitbucket.org/cacaovm
  /cacao-
  staging/src/c8d3fbab864c3243f97629fcfa8d84ba71f38157/src/vm/jit/alpha/linux
  /md-os.cpp?at=default&fileviewer=file-view-default#md-os.cpp-65)

  I don't know much about the qemu source code and cannot say where this
  is coming from at first glance. The gen_invalid function uses pc_next,
  which sounds like the next instruction, not the next-to-next ;). In
  theory it could actually be the kernel's fault, although I consider
  this unlikely.

  This is qemu-system-alpha with apparently the last Debian which
  existed for Alpha (lenny). The kernel is 2.6.26-2-alpha-generic
  (Debian 2.6.26-29). Observed with qemu git 1b3e80082b, but I guess it
  is the same with any version.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1810545/+subscriptions

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Qemu-devel] [Bug 1810545] Re: [alpha] Strange exception address reported
  2019-01-07 17:57 ` Peter Maydell
@ 2019-01-07 19:00   ` Peter Maydell
  2019-01-07 22:17     ` Richard Henderson
  0 siblings, 1 reply; 8+ messages in thread
From: Peter Maydell @ 2019-01-07 19:00 UTC (permalink / raw)
  To: QEMU Developers, Richard Henderson

On Mon, 7 Jan 2019 at 18:10, Peter Maydell <peter.maydell@linaro.org> wrote:
(re: https://bugs.launchpad.net/bugs/1810545)

> The problem seems to be that the PC we report for an OPCDEC
> is first selected by gen_invalid()/gen_excp() in
> target/alpha/translate.c, which uses pc_next (ie the insn's
> address plus 4). But that is then handed through to our custom
> PALcode (https://git.qemu.org/?p=qemu-palcode.git;a=blob;f=pal.S;h=1781c4b415700ca3a68af07fdae90ae43e722501;hb=HEAD) which does
>   addq    p6, 4, p1  // increment past the faulting insn
> resulting in insn + 8.
>
> That is, the palcode and the QEMU code have a disagreement about what
> the (private) API between them is. I'm not sure which side is wrong and
> should be corrected. I think the linux-user code assumes the same thing
> that translate.c is doing, so perhaps the palcode.

Richard -- any suggestions for which side of this API we should
be changing?

thanks
-- PMM

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Qemu-devel] [Bug 1810545] Re: [alpha] Strange exception address reported
  2019-01-07 19:00   ` Peter Maydell
@ 2019-01-07 22:17     ` Richard Henderson
  0 siblings, 0 replies; 8+ messages in thread
From: Richard Henderson @ 2019-01-07 22:17 UTC (permalink / raw)
  To: Peter Maydell, QEMU Developers

On 1/8/19 5:00 AM, Peter Maydell wrote:
> On Mon, 7 Jan 2019 at 18:10, Peter Maydell <peter.maydell@linaro.org> wrote:
> (re: https://bugs.launchpad.net/bugs/1810545)
> 
>> The problem seems to be that the PC we report for an OPCDEC
>> is first selected by gen_invalid()/gen_excp() in
>> target/alpha/translate.c, which uses pc_next (ie the insn's
>> address plus 4). But that is then handed through to our custom
>> PALcode (https://git.qemu.org/?p=qemu-palcode.git;a=blob;f=pal.S;h=1781c4b415700ca3a68af07fdae90ae43e722501;hb=HEAD) which does
>>   addq    p6, 4, p1  // increment past the faulting insn
>> resulting in insn + 8.
>>
>> That is, the palcode and the QEMU code have a disagreement about what
>> the (private) API between them is. I'm not sure which side is wrong and
>> should be corrected. I think the linux-user code assumes the same thing
>> that translate.c is doing, so perhaps the palcode.
> 
> Richard -- any suggestions for which side of this API we should
> be changing?

Probably the palcode side.  I'll take care of it.


r~

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Qemu-devel] [Bug 1810545] Re: [alpha] Strange exception address reported
  2019-01-04 18:21 [Qemu-devel] [Bug 1810545] [NEW] [alpha] Strange exception address reported Stefan Ring
  2019-01-04 19:05 ` [Qemu-devel] [Bug 1810545] " Peter Maydell
  2019-01-07 17:57 ` Peter Maydell
@ 2019-01-08 11:47 ` Peter Maydell
  2019-01-08 21:13 ` Stefan Ring
  2019-04-24  5:28 ` Thomas Huth
  4 siblings, 0 replies; 8+ messages in thread
From: Peter Maydell @ 2019-01-08 11:47 UTC (permalink / raw)
  To: qemu-devel

commit ac89de40ef5d4eb1704aa now in QEMU git master updates the palcode
guest ROM blob to a version which includes the fix for this bug.


** Changed in: qemu
       Status: New => Fix Committed

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1810545

Title:
  [alpha] Strange exception address reported

Status in QEMU:
  Fix Committed

Bug description:
  For some reason the SIGILL handler receives a different address under
  qemu than it used to on real hardware. I don't know specifics about
  the hardware used back then – it was some sort of 21264a somewhere
  between 600-800 MHz –, and I cannot say anything about the kernel as
  well, but I know that it delivered the faulting address +4, while
  under qemu it receives +8. I know because CACAO, an early Java JIT
  compiler extracts the address from the SIGILL handler and inspects the
  code at the faulting site, and it has substracted 4 from the handler
  address since the dawn of time, and this used to produce the desired
  result on the Alpha hardware. It actually ran on two different Alpha
  machines over the years, and both behaved identically.

  The handler looks like this:
  void handler_sigill(int sig, siginfo_t *siginfo, void *_p)
  {
    uintptr_t trap_address = (uintptr_t) (((ucontext_t*) _p)->uc_mcontext.sc_pc) - 4;
  }

  (paraphrasing, the actual code is here: https://bitbucket.org/cacaovm
  /cacao-
  staging/src/c8d3fbab864c3243f97629fcfa8d84ba71f38157/src/vm/jit/alpha/linux
  /md-os.cpp?at=default&fileviewer=file-view-default#md-os.cpp-65)

  I don't know much about the qemu source code and cannot say where this
  is coming from at first glance. The gen_invalid function uses pc_next,
  which sounds like the next instruction, not the next-to-next ;). In
  theory it could actually be the kernel's fault, although I consider
  this unlikely.

  This is qemu-system-alpha with apparently the last Debian which
  existed for Alpha (lenny). The kernel is 2.6.26-2-alpha-generic
  (Debian 2.6.26-29). Observed with qemu git 1b3e80082b, but I guess it
  is the same with any version.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1810545/+subscriptions

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Qemu-devel] [Bug 1810545] Re: [alpha] Strange exception address reported
  2019-01-04 18:21 [Qemu-devel] [Bug 1810545] [NEW] [alpha] Strange exception address reported Stefan Ring
                   ` (2 preceding siblings ...)
  2019-01-08 11:47 ` Peter Maydell
@ 2019-01-08 21:13 ` Stefan Ring
  2019-04-24  5:28 ` Thomas Huth
  4 siblings, 0 replies; 8+ messages in thread
From: Stefan Ring @ 2019-01-08 21:13 UTC (permalink / raw)
  To: qemu-devel

Works, thanks!

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1810545

Title:
  [alpha] Strange exception address reported

Status in QEMU:
  Fix Committed

Bug description:
  For some reason the SIGILL handler receives a different address under
  qemu than it used to on real hardware. I don't know specifics about
  the hardware used back then – it was some sort of 21264a somewhere
  between 600-800 MHz –, and I cannot say anything about the kernel as
  well, but I know that it delivered the faulting address +4, while
  under qemu it receives +8. I know because CACAO, an early Java JIT
  compiler extracts the address from the SIGILL handler and inspects the
  code at the faulting site, and it has substracted 4 from the handler
  address since the dawn of time, and this used to produce the desired
  result on the Alpha hardware. It actually ran on two different Alpha
  machines over the years, and both behaved identically.

  The handler looks like this:
  void handler_sigill(int sig, siginfo_t *siginfo, void *_p)
  {
    uintptr_t trap_address = (uintptr_t) (((ucontext_t*) _p)->uc_mcontext.sc_pc) - 4;
  }

  (paraphrasing, the actual code is here: https://bitbucket.org/cacaovm
  /cacao-
  staging/src/c8d3fbab864c3243f97629fcfa8d84ba71f38157/src/vm/jit/alpha/linux
  /md-os.cpp?at=default&fileviewer=file-view-default#md-os.cpp-65)

  I don't know much about the qemu source code and cannot say where this
  is coming from at first glance. The gen_invalid function uses pc_next,
  which sounds like the next instruction, not the next-to-next ;). In
  theory it could actually be the kernel's fault, although I consider
  this unlikely.

  This is qemu-system-alpha with apparently the last Debian which
  existed for Alpha (lenny). The kernel is 2.6.26-2-alpha-generic
  (Debian 2.6.26-29). Observed with qemu git 1b3e80082b, but I guess it
  is the same with any version.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1810545/+subscriptions

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Qemu-devel] [Bug 1810545] Re: [alpha] Strange exception address reported
  2019-01-04 18:21 [Qemu-devel] [Bug 1810545] [NEW] [alpha] Strange exception address reported Stefan Ring
                   ` (3 preceding siblings ...)
  2019-01-08 21:13 ` Stefan Ring
@ 2019-04-24  5:28 ` Thomas Huth
  4 siblings, 0 replies; 8+ messages in thread
From: Thomas Huth @ 2019-04-24  5:28 UTC (permalink / raw)
  To: qemu-devel

** Changed in: qemu
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1810545

Title:
  [alpha] Strange exception address reported

Status in QEMU:
  Fix Released

Bug description:
  For some reason the SIGILL handler receives a different address under
  qemu than it used to on real hardware. I don't know specifics about
  the hardware used back then – it was some sort of 21264a somewhere
  between 600-800 MHz –, and I cannot say anything about the kernel as
  well, but I know that it delivered the faulting address +4, while
  under qemu it receives +8. I know because CACAO, an early Java JIT
  compiler extracts the address from the SIGILL handler and inspects the
  code at the faulting site, and it has substracted 4 from the handler
  address since the dawn of time, and this used to produce the desired
  result on the Alpha hardware. It actually ran on two different Alpha
  machines over the years, and both behaved identically.

  The handler looks like this:
  void handler_sigill(int sig, siginfo_t *siginfo, void *_p)
  {
    uintptr_t trap_address = (uintptr_t) (((ucontext_t*) _p)->uc_mcontext.sc_pc) - 4;
  }

  (paraphrasing, the actual code is here: https://bitbucket.org/cacaovm
  /cacao-
  staging/src/c8d3fbab864c3243f97629fcfa8d84ba71f38157/src/vm/jit/alpha/linux
  /md-os.cpp?at=default&fileviewer=file-view-default#md-os.cpp-65)

  I don't know much about the qemu source code and cannot say where this
  is coming from at first glance. The gen_invalid function uses pc_next,
  which sounds like the next instruction, not the next-to-next ;). In
  theory it could actually be the kernel's fault, although I consider
  this unlikely.

  This is qemu-system-alpha with apparently the last Debian which
  existed for Alpha (lenny). The kernel is 2.6.26-2-alpha-generic
  (Debian 2.6.26-29). Observed with qemu git 1b3e80082b, but I guess it
  is the same with any version.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1810545/+subscriptions

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2019-04-24  5:35 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-01-04 18:21 [Qemu-devel] [Bug 1810545] [NEW] [alpha] Strange exception address reported Stefan Ring
2019-01-04 19:05 ` [Qemu-devel] [Bug 1810545] " Peter Maydell
2019-01-07 17:57 ` Peter Maydell
2019-01-07 19:00   ` Peter Maydell
2019-01-07 22:17     ` Richard Henderson
2019-01-08 11:47 ` Peter Maydell
2019-01-08 21:13 ` Stefan Ring
2019-04-24  5:28 ` Thomas Huth

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.