[Qemu-commits] [qemu/qemu] 0c6c43: ui/cocoa.m: prevent stuck command key when going i...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: 0c6c43955421764998eb0dd1863ee8b38a3ff1c1
      
https://github.com/qemu/qemu/commit/0c6c43955421764998eb0dd1863ee8b38a3ff1c1
  Author: John Arbuckle <address@hidden>
  Date:   2018-07-24 (Tue, 24 Jul 2018)

  Changed paths:
    M ui/cocoa.m

  Log Message:
  -----------
  ui/cocoa.m: prevent stuck command key when going into full screen mode

When the user pushes Command-F in QEMU while the mouse is ungrabbed, QEMU
goes into full screen mode. When the user finally releases the command key,
it is sent to the guest as an event. The makes the guest operating system
think the command key is down when it is really up. To prevent this situation
from happening, we simply drop the first command key event after the user has
gone into full screen mode using Command-F.

Signed-off-by: John Arbuckle <address@hidden>
Message-id: address@hidden
Reviewed-by: Peter Maydell <address@hidden>
Signed-off-by: Peter Maydell <address@hidden>


  Commit: 042374c92e83da5c8f906b9b97814a21eac2a09f
      
https://github.com/qemu/qemu/commit/042374c92e83da5c8f906b9b97814a21eac2a09f
  Author: Peter Maydell <address@hidden>
  Date:   2018-07-24 (Tue, 24 Jul 2018)

  Changed paths:
    M hw/intc/arm_gicv3_cpuif.c

  Log Message:
  -----------
  hw/intc/arm_gicv3: Check correct HCR_EL2 bit when routing IRQ

In icc_dir_write() we were incorrectly checking HCR_EL2.FMO
when determining whether IRQ should be routed to EL2; this should
be HCR_EL2.IMO (compare the GICv3 pseudocode ICC_DIR_EL1[]).
Use the correct mask.

Signed-off-by: Peter Maydell <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Message-id: address@hidden


  Commit: 1a5182c0d2eaa8dc8e7dbd914fba8d07d5595fe0
      
https://github.com/qemu/qemu/commit/1a5182c0d2eaa8dc8e7dbd914fba8d07d5595fe0
  Author: Peter Maydell <address@hidden>
  Date:   2018-07-24 (Tue, 24 Jul 2018)

  Changed paths:
    M hw/intc/armv7m_nvic.c
    M hw/intc/trace-events

  Log Message:
  -----------
  target/arm: Escalate to correct HardFault when AIRCR.BFHFNMINS is set

When we escalate a v8M exception to HardFault, if AIRCR.BFHFNMINNS is
set then we need to decide whether it should become a secure HardFault
or a nonsecure HardFault. We should always escalate to the same
target security state as the original exception. The current code
tries to test this using the 'secure' bool, which is not right because
that flag indicates whether the target security state only for
banked exceptions; the effect was that we were incorrectly escalating
always-secure exceptions like SecureFault to a nonsecure HardFault.

Fix this by defining, logging and using a new 'targets_secure' bool
which tracks the condition we actually want.

Signed-off-by: Peter Maydell <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Message-id: address@hidden


Compare: https://github.com/qemu/qemu/compare/768cef2974fb...1a5182c0d2ea
      **NOTE:** This service been marked for deprecation: 
https://developer.github.com/changes/2018-04-25-github-services-deprecation/

      Functionality will be removed from GitHub.com on January 31st, 2019.