qemu-commits
[Top][All Lists]
Advanced

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

[Qemu-commits] [qemu/qemu] f900b1: target/arm: Fix handling of cortex-m


From: Peter Maydell
Subject: [Qemu-commits] [qemu/qemu] f900b1: target/arm: Fix handling of cortex-m FTYPE flag in...
Date: Tue, 26 Nov 2019 11:47:25 -0800

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: f900b1e5b087a02199fbb6de7038828008e9e419
      
https://github.com/qemu/qemu/commit/f900b1e5b087a02199fbb6de7038828008e9e419
  Author: Jean-Hugues DeschĂȘnes <address@hidden>
  Date:   2019-11-26 (Tue, 26 Nov 2019)

  Changed paths:
    M target/arm/m_helper.c

  Log Message:
  -----------
  target/arm: Fix handling of cortex-m FTYPE flag in EXCRET

According to the PushStack() pseudocode in the armv7m RM,
bit 4 of the LR should be set to NOT(CONTROL.PFCA) when
an FPU is present. Current implementation is doing it for
armv8, but not for armv7. This patch makes the existing
logic applicable to both code paths.

Signed-off-by: Jean-Hugues Deschenes <address@hidden>
Reviewed-by: Peter Maydell <address@hidden>
Signed-off-by: Peter Maydell <address@hidden>


  Commit: f0138990ce1e8166ef1488e3b77b2d21ce71ede3
      
https://github.com/qemu/qemu/commit/f0138990ce1e8166ef1488e3b77b2d21ce71ede3
  Author: Edgar E. Iglesias <address@hidden>
  Date:   2019-11-26 (Tue, 26 Nov 2019)

  Changed paths:
    M hw/arm/xlnx-versal.c
    M include/hw/arm/xlnx-versal.h

  Log Message:
  -----------
  hw/arm: versal: Add the CRP as unimplemented

Add the CRP as unimplemented thus avoiding bus errors when
guests access these registers.

Signed-off-by: Edgar E. Iglesias <address@hidden>
Reviewed-by: Alistair Francis <address@hidden>
Reviewed-by: Luc Michel <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>


  Commit: 7cf95aed53c8770a338617ef40d5f37d2c197853
      
https://github.com/qemu/qemu/commit/7cf95aed53c8770a338617ef40d5f37d2c197853
  Author: Marc Zyngier <address@hidden>
  Date:   2019-11-26 (Tue, 26 Nov 2019)

  Changed paths:
    M target/arm/helper.c

  Log Message:
  -----------
  target/arm: Fix ISR_EL1 tracking when executing at EL2

The ARMv8 ARM states when executing at EL2, EL3 or Secure EL1,
ISR_EL1 shows the pending status of the physical IRQ, FIQ, or
SError interrupts.

Unfortunately, QEMU's implementation only considers the HCR_EL2
bits, and ignores the current exception level. This means a hypervisor
trying to look at its own interrupt state actually sees the guest
state, which is unexpected and breaks KVM as of Linux 5.3.

Instead, check for the running EL and return the physical bits
if not running in a virtualized context.

Fixes: 636540e9c40b
Cc: address@hidden
Reported-by: Quentin Perret <address@hidden>
Signed-off-by: Marc Zyngier <address@hidden>
Message-id: address@hidden
Reviewed-by: Peter Maydell <address@hidden>
Reviewed-by: Edgar E. Iglesias <address@hidden>
Signed-off-by: Peter Maydell <address@hidden>


  Commit: 6a4ef4e5d1084ce41fafa7d470a644b0fd3d9317
      
https://github.com/qemu/qemu/commit/6a4ef4e5d1084ce41fafa7d470a644b0fd3d9317
  Author: Marc Zyngier <address@hidden>
  Date:   2019-11-26 (Tue, 26 Nov 2019)

  Changed paths:
    M target/arm/helper.c

  Log Message:
  -----------
  target/arm: Honor HCR_EL2.TID3 trapping requirements

HCR_EL2.TID3 mandates that access from EL1 to a long list of id
registers traps to EL2, and QEMU has so far ignored this requirement.

This breaks (among other things) KVM guests that have PtrAuth enabled,
while the hypervisor doesn't want to expose the feature to its guest.
To achieve this, KVM traps the ID registers (ID_AA64ISAR1_EL1 in this
case), and masks out the unsupported feature.

QEMU not honoring the trap request means that the guest observes
that the feature is present in the HW, starts using it, and dies
a horrible death when KVM injects an UNDEF, because the feature
*really* isn't supported.

Do the right thing by trapping to EL2 if HCR_EL2.TID3 is set.

Note that this change does not include trapping of the MVFR
registers from AArch32 (they are accessed via the VMRS
instruction and need to be handled in a different way).

Reported-by: Will Deacon <address@hidden>
Signed-off-by: Marc Zyngier <address@hidden>
Tested-by: Will Deacon <address@hidden>
Message-id: address@hidden
[PMM: added missing accessfn line for ID_AA4PFR2_EL1_RESERVED;
 changed names of access functions to include _tid3]
Reviewed-by: Peter Maydell <address@hidden>
Signed-off-by: Peter Maydell <address@hidden>


  Commit: 5f64adc138848109e4007556dc8e3a641550104d
      
https://github.com/qemu/qemu/commit/5f64adc138848109e4007556dc8e3a641550104d
  Author: Peter Maydell <address@hidden>
  Date:   2019-11-26 (Tue, 26 Nov 2019)

  Changed paths:
    M hw/arm/xlnx-versal.c
    M include/hw/arm/xlnx-versal.h
    M target/arm/helper.c
    M target/arm/m_helper.c

  Log Message:
  -----------
  Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20191126' 
into staging

target-arm queue:
 * handle FTYPE flag correctly in v7M exception return
   for v7M CPUs with an FPU (v8M CPUs were already correct)
 * versal: Add the CRP as unimplemented
 * Fix ISR_EL1 tracking when executing at EL2
 * Honor HCR_EL2.TID3 trapping requirements

# gpg: Signature made Tue 26 Nov 2019 14:11:50 GMT
# gpg:                using RSA key E1A5C593CD419DE28E8315CF3C2525ED14360CDE
# gpg:                issuer "address@hidden"
# gpg: Good signature from "Peter Maydell <address@hidden>" [ultimate]
# gpg:                 aka "Peter Maydell <address@hidden>" [ultimate]
# gpg:                 aka "Peter Maydell <address@hidden>" [ultimate]
# Primary key fingerprint: E1A5 C593 CD41 9DE2 8E83  15CF 3C25 25ED 1436 0CDE

* remotes/pmaydell/tags/pull-target-arm-20191126:
  target/arm: Honor HCR_EL2.TID3 trapping requirements
  target/arm: Fix ISR_EL1 tracking when executing at EL2
  hw/arm: versal: Add the CRP as unimplemented
  target/arm: Fix handling of cortex-m FTYPE flag in EXCRET

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


Compare: https://github.com/qemu/qemu/compare/0d4f9d7dc783...5f64adc13884



reply via email to

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