[Qemu-commits] [qemu/qemu] 3b418d: hw/arm/highbank: Don't segfault on unknown CPU nam...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: 3b418d0c45fccd850f9ad9eb4bf9bdcd96b8e6f7
      
https://github.com/qemu/qemu/commit/3b418d0c45fccd850f9ad9eb4bf9bdcd96b8e6f7
  Author: Peter Maydell <address@hidden>
  Date:   2014-04-04 (Fri, 04 Apr 2014)

  Changed paths:
    M hw/arm/highbank.c

  Log Message:
  -----------
  hw/arm/highbank: Don't segfault on unknown CPU names

If the user passes an unknown CPU name via the '-cpu' option, exit
with an error message rather than segfaulting.

Signed-off-by: Peter Maydell <address@hidden>
Reviewed-by: Rob Herring <address@hidden>


  Commit: d097696eba076da781967827e59f66a7857c8ecb
      
https://github.com/qemu/qemu/commit/d097696eba076da781967827e59f66a7857c8ecb
  Author: Peter Maydell <address@hidden>
  Date:   2014-04-04 (Fri, 04 Apr 2014)

  Changed paths:
    M hw/arm/highbank.c
    M hw/arm/vexpress.c

  Log Message:
  -----------
  hw/arm/vexpress, hw/arm/highbank: Don't insist that CPU has reset-cbar 
property

For the machine models which can have a Cortex-A15 CPU (vexpress-a15 and
midway), silently continue if the CPU object has no reset-cbar property
rather than failing. This allows these boards to be used under KVM with
the "-cpu host" option, since the 'host' CPU object has no reset-cbar
property.

Signed-off-by: Peter Maydell <address@hidden>
Reviewed-by: Rob Herring <address@hidden>


  Commit: cd7ccc83512a0cba5aa0c778e7507f267cfb1b16
      
https://github.com/qemu/qemu/commit/cd7ccc83512a0cba5aa0c778e7507f267cfb1b16
  Author: Andrei Warkentin <address@hidden>
  Date:   2014-04-04 (Fri, 04 Apr 2014)

  Changed paths:
    M translate-all.c

  Log Message:
  -----------
  page_check_range: don't bail out early after unprotecting page

When checking a page range, if we found that a page was
made read-only by QEMU because it contained translated code,
we were incorrectly returning immediately after unprotecting
that page, rather than continuing to check the entire range,
so we might fail to unprotect pages later in the range, or
might incorrectly return a "success" result even if later
pages were not writable.

In particular, this could cause segfaults in a case where
signals are delivered back to back on a target architecture
which uses trampoline code in the stack frame (as AArch64
currently does). The second signal causes a segfault because
the frame cannot be written to (it was protected because
we translated and executed the restorer trampoline, and the
unprotect logic did not unprotect the whole range).

Signed-off-by: Andrei Warkentin <address@hidden
[PMM: expanded commit message a bit]
Reviewed-by: Richard Henderson <address@hidden>
Signed-off-by: Peter Maydell <address@hidden>


  Commit: bae2c270906475093e3d5f4c3103dbe67bf82009
      
https://github.com/qemu/qemu/commit/bae2c270906475093e3d5f4c3103dbe67bf82009
  Author: Peter Maydell <address@hidden>
  Date:   2014-04-04 (Fri, 04 Apr 2014)

  Changed paths:
    M cpu-exec.c

  Log Message:
  -----------
  cpu-exec: Unlock tb_lock if we longjmp out of code generation

If the guest attempts to execute from unreadable memory, this will
cause us to longjmp back to the main loop from inside the
target frontend decoder. For linux-user mode, this means we will
still hold the tb_ctx.tb_lock, and will deadlock when we try to
start executing code again. Unlock the lock in the return-from-longjmp
code path to avoid this.

Signed-off-by: Peter Maydell <address@hidden>
Acked-by: Andrei Warkentin <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>


Compare: https://github.com/qemu/qemu/compare/5913815a1738...bae2c2709064