The Cortex-A15 and Cortex-A7 both have EL2; now we've implemented
it properly we can enable the feature bit.
Backports commit 436c0cbbeb38dd97c02fe921a7cb253a18afdd86 from qemu
Hyp mode is an exception to the general rule that each AArch32
mode has its own r13, r14 and SPSR -- it has a banked r13 and
SPSR but shares its r14 with User and System mode. We were
incorrectly implementing it as banked, which meant that on
entry to Hyp mode r14 was 0 rather than the USR/SYS r14.
We provide a new function r14_bank_number() which is like
the existing bank_number() but provides the index into
env->banked_r14[]; bank_number() provides the index to use
for env->banked_r13[] and env->banked_cpsr[].
All the points in the code that were using bank_number()
to index into env->banked_r14[] are updated for consintency:
* switch_mode() -- this is the only place where we fix
an actual bug
* aarch64_sync_32_to_64() and aarch64_sync_64_to_32():
no behavioural change as we already special-cased Hyp R14
* kvm32.c: no behavioural change since the guest can't ever
be in Hyp mode, but conceptually the right thing to do
* msr_banked()/mrs_banked(): we can never get to the case
that accesses banked_r14[] with tgtmode == ARM_CPU_MODE_HYP,
so no behavioural change
Backports commit 593cfa2b637b92d37eef949653840dc065cdb960 from qemu
In commit 8a0fc3a29fc2315325400 we tried to implement HCR_EL2.{VI,VF},
but we got it wrong and had to revert it.
In that commit we implemented them as simply tracking whether there
is a pending virtual IRQ or virtual FIQ. This is not correct -- these
bits cause a software-generated VIRQ/VFIQ, which is distinct from
whether there is a hardware-generated VIRQ/VFIQ caused by the
external interrupt controller. So we need to track separately
the HCR_EL2 bit state and the external virq/vfiq line state, and
OR the two together to get the actual pending VIRQ/VFIQ state.
Fixes: 8a0fc3a29fc2315325400c738f807d0d4ae0ab7f
Backports commit 89430fc6f80a5aef1d4cbd6fc26b40c30793786c from qemu
Currently we track the state of the four irq lines from the GIC
only via the cs->interrupt_request or KVM irq state. That means
that we assume that an interrupt is asserted if and only if the
external line is set. This assumption is incorrect for VIRQ
and VFIQ, because the HCR_EL2.{VI,VF} bits allow assertion
of VIRQ and VFIQ separately from the state of the external line.
To handle this, start tracking the state of the external lines
explicitly in a CPU state struct field, as is common practice
for devices.
The complicated part of this is dealing with inbound migration
from an older QEMU which didn't have this state. We assume in
that case that the older QEMU did not implement the HCR_EL2.{VI,VF}
bits as generating interrupts, and so the line state matches
the current state in cs->interrupt_request. (This is not quite
true between commit 8a0fc3a29fc2315325400c7 and its revert, but
that commit is broken and never made it into any released QEMU
version.)
Backports relevant parts of commit ed89f078ff3d6684ce3e538e4777a3bb4ec3e2b1 from qemu
This reverts commit 8a0fc3a29fc2315325400c738f807d0d4ae0ab7f.
The implementation of HCR.VI and VF in that commit is not
correct -- they do not track the overall "is there a pending
VIRQ or VFIQ" status, but whether there is a pending interrupt
due to "this mechanism", ie the hypervisor having set the VI/VF
bits. The overall pending state for VIRQ and VFIQ is effectively
the logical OR of the inbound lines from the GIC with the
VI and VF bits. Commit 8a0fc3a29fc231 would result in pending
VIRQ/VFIQ possibly being lost when the hypervisor wrote to HCR.
As a preliminary to implementing the HCR.VI/VF feature properly,
revert the broken one entirely.
Backports commit c624ea0fa7ffc9e2cc3e2b36c92b5c960954489f from qemu
The test was incomplete and incorrectly caused debug exceptions to be
generated when returning to EL2 after a failed attempt to single-step
an EL1 instruction. Fix this while cleaning up the function a little.
Backports commit 22af90255ec2100a44cbbb7f0460ba15eed79538 from qemu
Before we supported direct execution from MMIO regions, we
implemented workarounds in commit 720424359917887c926a33d2
which let us avoid doing so, even if the SAU or MPU region
was less than page-sized.
Once we implemented execute-from-MMIO, we removed part
of those workarounds in commit d4b6275df320cee76; but
we forgot the one in get_phys_addr_pmsav8() which
suppressed use of small SAU regions in executable regions.
Remove that workaround now.
Backports commit 521ed6b4015ba39a2e39c65a94643f3e6412edc4 from qemu
Now that we have full support for small regions, including execution,
we can remove the workarounds where we marked all small regions as
non-executable for the M-profile MPU and SAU.
Backports commit d4b6275df320cee764d56b194b1898547f545857 from qemu
Add support for MMU protection regions that are smaller than
TARGET_PAGE_SIZE. We do this by marking the TLB entry for those
pages with a flag TLB_RECHECK. This flag causes us to always
take the slow-path for accesses. In the slow path we can then
special case them to always call tlb_fill() again, so we have
the correct information for the exact address being accessed.
This change allows us to handle reading and writing from small
regions; we cannot deal with execution from the small region.
Backports commit 55df6fcf5476b44bc1b95554e686ab3e91d725c5 from qemu
Remove a TODO comment about implementing the vectored interrupt
controller. We have had an implementation of that for a decade;
it's in hw/intc/pl190.c.
Backports commit e24ad484909e7a00ca4f6332f3698facf0ba3394 from qemu
The tcg-op.h header was missing the usual guard against multiple
inclusion; add it.
(Spotted by lgtm.com's static analyzer.)
Backports commit a7ce790a029bd94eb320d8c69f38900f5233997e from qemu
Add a new flag to mark memory region that are used as non-volatile, by
NVDIMM for example. That bit is propagated down to the flat view, and
reflected in HMP info mtree with a "nv-" prefix on the memory type.
This way, guest_phys_blocks_region_add() can skip the NV memory
regions for dumps and TCG memory clear in a following patch.
Backports commit c26763f8ec70b1011098cab0da9178666d8256a5 from qemu
Fix the SYSCALL instruction in 64-bit (long mode). The RF flag
should be cleared in R11 as well as in the RFLAGS. Intel
and AMD CPUs behave same. AMD has this documented in the
APM vol 3.
Backports commit 1a1435dd61e28c1e3b70971107d72a7d05b28d03 from qemu
ATS1HR and ATS1HW (which allow AArch32 EL2 to do address translations
on the EL2 translation regime) were implemented in commit 14db7fe09a2c8.
However, we got them wrong: these should do stage 1 address translations
as defined for NS-EL2, which is ARMMMUIdx_S1E2. We were incorrectly
making them perform stage 2 translations.
A few years later in commit 1313e2d7e2cd we forgot entirely that
we'd implemented ATS1Hx, and added a comment that ATS1Hx were
"not supported yet". Remove the comment; there is no extra code
needed to handle these operations in do_ats_write(), because
arm_s1_regime_using_lpae_format() returns true for ARMMMUIdx_S1E2,
which forces 64-bit PAR format.
Backports commit 23463e0e4aeb2f0a9c60549a2c163f4adc0b8512 from qemu
In do_ats_write() we construct a PAR value based on the result
of the translation. A comment says "S2WLK and FSTAGE are always
zero, because we don't implement virtualization".
Since we do in fact now implement virtualization, add the missing
code that sets these bits based on the reported ARMMMUFaultInfo.
(These bits are named PTW and S in ARMv8, so we follow that
convention in the new comments in this patch.)
Backports commit 0f7b791b35f24cb1333f779705a3f6472e6935de from qemu
In handle_vec_simd_shli() we have a check:
if (size > 3 && !is_q) {
unallocated_encoding(s);
return;
}
However this can never be true, because we calculate
int size = 32 - clz32(immh) - 1;
where immh is a 4 bit field which we know cannot be all-zeroes.
So the clz32() return must be in {28,29,30,31} and the resulting
size is in {0,1,2,3}, and "size > 3" is never true.
This unnecessary code confuses Coverity's analysis:
in CID 1396476 it thinks we might later index off the
end of an array because the condition implies that we
might have a size > 3.
Remove the code, and instead assert that the size is in [0..3],
since the decode that enforces that is somewhat distant from
this function.
Backports commit f6c98f91f56031141a47f86225fdc30f0f9f84fb from qemu
The divdeu instruction was added to ISA 2.06 (Power7).
Exclude this block from older cpus.
Fixes: 27ae5109a2ba (softfloat: Specialize udiv_qrnnd for ppc64)
Backports commit 7370981bd1ef58b3c20ba8b83cc342d1c61bc773 from qemu
When populating id registers from kvm, on a host that doesn't support
aarch32 mode at all, neither arm_div nor jazelle will be supported either.
Backports commit 0f8d06f16c9d1041d728d09d464462ebe713c662 from qemu
Coldfire defines an "Unsupported instruction" exception if execution
of a valid instruction is attempted but the required hardware is not
present in the processor.
We use it with instructions that are in fact undefined or illegal,
and the exception expected in this case by the kernel is the
illegal exception, so this patch fixes that.
Backports commit b9f8e55bf7e994e192ab7360830731580384b813 from qemu
While it would be possible to concatenate input files with make,
passing the original input files to decodetree.py allows us to
generate error messages which allows compilation environments
(read: emacs) to next-error to the correct input file.
Backports commit 6699ae6a8e74381583622502db8bd47fac381c9e from qemu
This allows trans_* expanders to be shared between decoders
for 32 and 16-bit insns, by not tying the expander to the
size of the insn that produced it.
This change requires adjusting the two existing users to match.
Backports commit 3a7be5546506be62d5c6c4b804119cedf9e367d6 from qemu
Allow argument sets to be shared between two decoders by avoiding
a re-declaration error. Make sure that anonymous argument sets
and anonymous formats have unique names.
Backports commit abd04f9290094f4eb7f3c07335766bbac3de22bb from qemu
As the release document ref below link (page 13):
https://software.intel.com/sites/default/files/managed/c5/15/\
architecture-instruction-set-extensions-programming-reference.pdf
PKU is supported in Skylake Server (Only Server) and later, and
on Intel(R) Xeon(R) Processor Scalable Family. So PKU is supposed
to be in Skylake-Server CPU model. And PKU's CPUID has been
exposed to QEMU. But PKU can't be find in Skylake-Server CPU
model in the code. So this patch will fix this issue in
Skylake-Server CPU model.
Backports commit 09b9ee643f90ef95e30e594df2a3c83ccaf75b1f from qemu
New CPU models mostly inherit features from ancestor Skylake-Server,
while addin new features: AVX512_VNNI, Intel PT.
SSBD support for speculative execution
side channel mitigations.
Note:
On Cascadelake, some capabilities (RDCL_NO, IBRS_ALL, RSBA,
SKIP_L1DFL_VMENTRY and SSB_NO) are enumerated by MSR.
These features rely on MSR based feature support patch.
Will be added later after that patch's in.
http://lists.nongnu.org/archive/html/qemu-devel/2018-09/msg00074.html
Backports commit c7a88b52f62b30c04158eeb07f73e3f72221b6a8 from qemu
Note RSBA is specially treated -- no matter host support it or not, qemu
pretends it is supported.
Backports commit d86f963694df27f11b3681ffd225c9362de1b634 from qemu
Intel SDM says for CPUID function 0DH, sub-function 0:
| • ECX enumerates the size (in bytes) required by the XSAVE instruction for an
| XSAVE area containing all the user state components supported by this
| processor.
| • EBX enumerates the size (in bytes) required by the XSAVE instruction for an
| XSAVE area containing all the user state components corresponding to bits
| currently set in XCR0.
Backports commit de2e68c902f7b6e438b0fa3cfedd74a06a20704f from qemu
Add prefix, suffix, operation descriptions, and other corrections
and amendments to the comment that describes MXU ASE.
Backports commit 093ade12179b6a3f679c100c0fe2a0a7d72068ba from qemu
Move MUL, S32M2I, S32I2M handling out of switch. These are all
instructions that do not depend on MXU_EN flag of MXU_CR.
Backports commit 87860df5511b972f0234a6b2cfaad5227c79b6b4 from qemu
Add support for emulating the S32I2M and S32M2I MXU instructions.
This commit also contains utility functions for reading/writing
to MXU registers. This is required for overall MXU instruction
support.
Backports commit 96992d1aa1b250c0fffc1ff2dad5e6e4f0b9815b from qemu
