The current A32/T32 decoder bases its "is VFP/Neon enabled?" check
on the FPSCR.EN bit. This is correct if EL1 is AArch32, but for
an AArch64 EL1 the logic is different: it must act as if FPSCR.EN
is always set. Instead, trapping must happen according to CPACR
bits for cp10/cp11; these cover all of FP/Neon, including the
FPSCR/FPSID/MVFR register accesses which FPSCR.EN does not affect.
Add support for CPACR checks (which are also required for ARMv7,
but were unimplemented because Linux happens not to use them)
and make sure they generate exceptions with the correct syndrome.

We actually return incorrect syndrome information for cases
where FP is disabled but the specific instruction bit pattern
is unallocated: strictly these should be the Uncategorized
exception, not a "SIMD disabled" exception. This should be
mostly harmless, and the structure of the A32/T32 VFP/Neon
decoder makes it painful to put the 'FP disabled?' checks in
the right places.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NPeter Crosthwaite <peter.crosthwaite@xilinx.com>

For the A64 instruction set, the only FP/Neon disable trap
is the CPACR FPEN bits, which may indicate "enabled", "disabled"
or "disabled for EL0". Add a bit to the AArch64 tb flags indicating
whether FP/Neon access is currently enabled and make the decoder
emit code to raise exceptions on use of FP/Neon insns if it is not.

We use a new flag in DisasContext rather than borrowing the
existing vfp_enabled flag because the A32/T32 decoder is going
to need both.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Acked-by: NPeter Crosthwaite <peter.crosthwaite@xilinx.com>
---
I'm aware this is a rather hard to review patch; sorry.
I have done an exhaustive check that we have fp access checks
in all code paths with the aid of the assertions added in the
next patch plus the code-coverage hack patch I posted to the
list earlier.

This patch is correct as of
09e03735 target-arm: A64: Add saturating accumulate ops (USQADD/SUQADD)
which was the last of the Neon insns to be added, so assuming
no refactoring of the code it should be fine.

For AArch32 exceptions, the only information provided about
the cause of an exception is the individual exception type (data
abort, undef, etc), which we store in cs->exception_index. For
AArch64, the CPU provides much more detail about the cause of
the exception, which can be found in the syndrome register.
Create a set of fields in CPUARMState which must be filled in
whenever an exception is raised, so that exception entry can
correctly fill in the syndrome register for the guest.
This includes the information which in AArch32 appears in
the DFAR and IFAR (fault address registers) and the DFSR
and IFSR (fault status registers) for data aborts and
prefetch aborts, since if we end up taking the MMU fault
to AArch64 rather than AArch32 this will need to end up
in different system registers.

This patch does a refactoring which moves the setting of the
AArch32 DFAR/DFSR/IFAR/IFSR from the point where the exception
is raised to the point where it is taken. (This is no change
for cores with an MMU, retains the existing clearly incorrect
behaviour for ARM946 of trashing the MP access permissions
registers which share the c5_data and c5_insn state fields,
and has no effect for v7M because we don't implement its
MPU fault status or address registers.)

As a side effect of the cleanup we fix a bug in the AArch64
linux-user mode code where we were passing a 64 bit fault
address through the 32 bit c6_data/c6_insn fields: it now
goes via the always-64-bit exception.vaddress.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NPeter Crosthwaite <peter.crosthwaite@xilinx.com>

Implement the DAIF system register which is a view of the
DAIF bits in PSTATE. To avoid needing a readfn, we widen
the daif field in CPUARMState to uint64_t.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NPeter Crosthwaite <peter.crosthwaite@xilinx.com>

Currently cpu.h defines a mixture of functions and types needed by
the rest of QEMU and those needed only by files within target-arm/.
Split the latter out into a new header so they aren't needlessly
exposed further than required.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NPeter Crosthwaite <peter.crosthwaite@xilinx.com>

Note that while such functions may exist both for *-user and softmmu,
only *-user uses the CPUState hook, while softmmu reuses the prototype
for calling it directly.
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Default to false.

Tidy variable naming and inline cast uses while at it.

Tested-by: Jia Liu <proljc@gmail.com> (or32)
Signed-off-by: NAndreas Färber <afaerber@suse.de>

This patch implements the ARM PMCCNTR register including
the disable and reset components of the PMCR register.
Signed-off-by: NAlistair Francis <alistair.francis@xilinx.com>
Message-id: bbf405e1feaf352cf39d5db402c9efcbd0f57c78.1393459802.git.alistair.francis@xilinx.com
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

Add support for AArch32 CRC32 and CRC32C instructions added in ARMv8
and add a CPU feature flag to enable these instructions.

The CRC32-C implementation used is the built-in qemu implementation
and The CRC-32 implementation is from zlib. This requires adding zlib
to LIBS to ensure it is linked for the linux-user binary.
Signed-off-by: NWill Newton <will.newton@linaro.org>
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
Message-id: 1393411566-24104-3-git-send-email-will.newton@linaro.org
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

There are various situations where we need to behave differently
depending on whether a given exception level is in AArch64 or
AArch32 state. The state of the current exception level is stored
in env->aarch64, but there's no equivalent guest-visible architected
state bits for the status of the exception levels "above" the
current one which may still affect execution. At the moment we
only support EL1 (ie no EL2 or EL3) and insist that AArch64
capable CPUs run with EL1 in AArch64 state, but these may change
in the future, so abstract out the "what state is this?" check
into a utility function which can be enhanced later if necessary.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NPeter Crosthwaite <peter.crosthwaite@xilinx.com>

Implement the AArch64 view of the CPACR. The AArch64
CPACR is defined to have a lot of RES0 bits, but since
the architecture defines that RES0 bits may be implemented
as reads-as-written and we know that a v8 CPU will have
no registered coprocessors for cp0..cp13 we can safely
implement the whole register this way.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NPeter Crosthwaite <peter.crosthwaite@xilinx.com>

To avoid complication in code that otherwise would not need to
care about whether EL1 is AArch32 or AArch64, we should store
the interrupt mask bits (CPSR.AIF in AArch32 and PSTATE.DAIF
in AArch64) in one place consistently regardless of EL1's mode.
Since AArch64 has an extra enable bit (D for debug exceptions)
which isn't visible in AArch32, this means we need to keep
the enables in env->pstate. (This is also consistent with the
general approach we're taking that we handle 32 bit CPUs as
being like AArch64/ARMv8 CPUs but which only run in 32 bit mode.)
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NPeter Crosthwaite <peter.crosthwaite@xilinx.com>

Emit the correct MMU index information for loads and stores from
A64 code, rather than hardwiring it to "always kernel mode",
by storing the exception level in the TB flags, and make
cpu_mmu_index() return the right answer when the CPU is in
AArch64 mode.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NPeter Crosthwaite <peter.crosthwaite@xilinx.com>

In AArch64 the breakpoint and watchpoint registers are mandatory, so the
kernel always accesses them on bootup. Implement dummy versions, which
read as written but have no actual effect.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NPeter Crosthwaite <peter.crosthwaite@xilinx.com>

Implement the AArch64 view of the generic timer system registers.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

Implement the AArch64 TTBR* registers. For v7 these were already 64 bits
to handle LPAE, but implemented as two separate uint32_t fields.
Combine them into a single uint64_t which can be used for all purposes.
Since this requires touching every use, take the opportunity to rename
the field to the architectural name.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NPeter Crosthwaite <peter.crosthwaite@xilinx.com>

Implement the A64 view of the VBAR system register.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NPeter Crosthwaite <peter.crosthwaite@xilinx.com>

Implement the AArch64 TCR_EL1, which is the 64 bit view of
the AArch32 TTBCR. (The uses of the bits in the register are
completely different, but in any given situation the CPU will
always interpret them one way or the other. In fact for QEMU EL1
is always 64 bit, but we share the state field because this
is the correct mapping to permit a future implementation of EL2.)
We also make the AArch64 view the 'master' as far as migration
and reset is concerned.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NPeter Crosthwaite <peter.crosthwaite@xilinx.com>

Implement the AArch64 view of the system control register SCTLR_EL1.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NPeter Crosthwaite <peter.crosthwaite@xilinx.com>

Implement the AArch64 memory attribute registers. Since QEMU doesn't
model caches it does not need to care about memory attributes at all,
and we can simply make these read-as-written.

We did not previously implement the AArch32 versions of the MAIR
registers, which went unnoticed because of the overbroad TLB_LOCKDOWN
reginfo definition; provide them now to keep the 64<->32 register
relationship clear.

We already provided AMAIR registers for 32 bit as simple RAZ/WI;
extend that to provide a 64 bit RAZ/WI AMAIR_EL1.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NPeter Crosthwaite <peter.crosthwaite@xilinx.com>

Implement the CurrentEL sysreg.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NPeter Crosthwaite <peter.crosthwaite@xilinx.com>

Make the cache ID system registers (CLIDR, CSSELR, CCSIDR, CTR)
visible to AArch64. These are mostly simple 64-bit extensions of the
existing 32 bit system registers and so can share reginfo definitions.
CTR needs to have a split definition, but we can clean up the
temporary user-mode implementation in favour of using the CPU-specified
reset value, and implement the system-mode-required semantics of
restricting its EL0 accessibility if SCTLR.UCT is not set.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NPeter Crosthwaite <peter.crosthwaite@xilinx.com>

The raw read and write functions were using the ARM_CP_64BIT flag in
ri->type to determine whether to treat the register's state field as
uint32_t or uint64_t; however AArch64 register info structs don't use
that flag. Abstract out the "how big is the field?" test into a
function and fix it to work for AArch64 registers. For this to work
we must ensure that the reginfo structs put into the hashtable have
the correct state field for their use, not the placeholder STATE_BOTH.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

All cpreg read and write functions now return 0, so we can clean up
their prototypes:
 * write functions return void
 * read functions return the value rather than taking a pointer
   to write the value to

This is a fairly mechanical change which makes only the bare
minimum set of changes to the callers of read and write functions.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NPeter Crosthwaite <peter.crosthwaite@xilinx.com>

Several of the system registers handled via the ARMCPRegInfo
mechanism have access trap control bits controlling whether the
registers are accessible to lower privilege levels. Replace
the existing mechanism (allowing the read and write functions
to return EXCP_UDEF if access is denied) with a dedicated
"check access rights" function pointer in the ARMCPRegInfo.
This will allow us to simplify some of the register definitions,
which no longer need read/write functions purely to handle
the access checks.

We take the opportunity to define the return value from the
access checking function in a way that allows us to set the
correct exception syndrome information for exceptions taken
to AArch64 (which may need to distinguish access failures due
to a configurable trap or enable from other kinds of access
failure).

This commit defines the new mechanism but does not move any
of the registers across to use it.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NPeter Crosthwaite <peter.crosthwaite@xilinx.com>

Remove the 'struct sr' from ARMCPUState -- it isn't actually used and is
a hangover from the original separate system register implementation used
by the SuSE linux-user-mode-only AArch64 target.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NPeter Crosthwaite <peter.crosthwaite@xilinx.com>

The SCTLR is full of bits for enabling or disabling various things, and so
there are many places in the code which check if certain bits are set.
Define some named constants for the SCTLR bits so these checks are easier
to read.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

This function will be needed for AArch32 ARMv8 support, so move it to
helper.c where it can be used by both targets. Also moves the code out
of line, but as it is quite a large function I don't believe this
should be a significant performance impact.
Signed-off-by: NWill Newton <will.newton@linaro.org>
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

When setting rounding modes we currently just hardcode the numeric values
for rounding modes in a big switch statement.

With AArch64 support coming, we will need to refer to these rounding modes
at different places throughout the code though, so let's better give them
names so we don't get confused by accident.
Signed-off-by: NAlexander Graf <agraf@suse.de>
[WN: Commit message tweak, use names from ARM ARM.]
Signed-off-by: NWill Newton <will.newton@linaro.org>
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NRichard Henderson <rth@twiddle.net>

In preparation for adding support for A64 load/store exclusive instructions,
widen the fields in the CPU state struct that deal with address and data values
for exclusives from 32 to 64 bits. Although in practice AArch64 and AArch32
exclusive accesses will be generally separate there are some odd theoretical
corner cases (eg you should be able to do the exclusive load in AArch32, take
an exception to AArch64 and successfully do the store exclusive there), and it's
also easier to reason about.

The changes in semantics for the variables are:
 exclusive_addr  -> extended to 64 bits; -1ULL for "monitor lost",
   otherwise always < 2^32 for AArch32
 exclusive_val   -> extended to 64 bits. 64 bit exclusives in AArch32 now
   use the high half of exclusive_val instead of a separate exclusive_high
 exclusive_high  -> is no longer used in AArch32; extended to 64 bits as
   it will be needed for AArch64's pair-of-64-bit-values exclusives.
 exclusive_test  -> extended to 64 bits, as it is an address. Since this is
   a linux-user-only field, in arm-linux-user it will always have the top
   32 bits zero.
 exclusive_info  -> stays 32 bits, as it is neither data nor address, but
   simply holds register indexes etc. AArch64 will be able to fit all its
   information into 32 bits as well.

Note that the refactoring of gen_store_exclusive() coincidentally fixes
a minor bug where ldrexd would incorrectly update the first CPU register
even if the load for the second register faulted.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NRichard Henderson <rth@twiddle.net>

When setting rounding modes we currently just hardcode the numeric values
for rounding modes in a big switch statement.

With AArch64 support coming, we will need to refer to these rounding modes
at different places throughout the code though, so let's better give them
names so we don't get confused by accident.
Signed-off-by: NAlexander Graf <agraf@suse.de>
[WN: Commit message tweak, use names from ARM ARM.]
Signed-off-by: NWill Newton <will.newton@linaro.org>
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NRichard Henderson <rth@twiddle.net>

In preparation for adding support for A64 load/store exclusive instructions,
widen the fields in the CPU state struct that deal with address and data values
for exclusives from 32 to 64 bits. Although in practice AArch64 and AArch32
exclusive accesses will be generally separate there are some odd theoretical
corner cases (eg you should be able to do the exclusive load in AArch32, take
an exception to AArch64 and successfully do the store exclusive there), and it's
also easier to reason about.

The changes in semantics for the variables are:
 exclusive_addr  -> extended to 64 bits; -1ULL for "monitor lost",
   otherwise always < 2^32 for AArch32
 exclusive_val   -> extended to 64 bits. 64 bit exclusives in AArch32 now
   use the high half of exclusive_val instead of a separate exclusive_high
 exclusive_high  -> is no longer used in AArch32; extended to 64 bits as
   it will be needed for AArch64's pair-of-64-bit-values exclusives.
 exclusive_test  -> extended to 64 bits, as it is an address. Since this is
   a linux-user-only field, in arm-linux-user it will always have the top
   32 bits zero.
 exclusive_info  -> stays 32 bits, as it is neither data nor address, but
   simply holds register indexes etc. AArch64 will be able to fit all its
   information into 32 bits as well.

Note that the refactoring of gen_store_exclusive() coincidentally fixes
a minor bug where ldrexd would incorrectly update the first CPU register
even if the load for the second register faulted.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NRichard Henderson <rth@twiddle.net>

The common pattern for system registers in a 64-bit capable ARM
CPU is that when in AArch32 the cp15 register is a view of the
bottom 32 bits of the 64-bit AArch64 system register; writes in
AArch32 leave the top half unchanged. The most natural way to
model this is to have the state field in the CPU struct be a
64 bit value, and simply have the AArch32 TCG code operate on
a pointer to its lower half.

For aarch64-linux-user the only registers we need to share like
this are the thread-local-storage ones. Widen their fields to
64 bits and provide the 64 bit reginfo struct to make them
visible in AArch64 state. Note that minor cleanup of the AArch64
system register encoding space means We can share the TPIDR_EL1
reginfo but need split encodings for TPIDR_EL0 and TPIDRRO_EL0.

Since we're touching almost every line in QEMU that uses the
c13_tls* fields in this patch anyway, we take the opportunity
to rename them in line with the standard ARM architectural names
for these registers.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NRichard Henderson <rth@twiddle.net>

The common pattern for system registers in a 64-bit capable ARM
CPU is that when in AArch32 the cp15 register is a view of the
bottom 32 bits of the 64-bit AArch64 system register; writes in
AArch32 leave the top half unchanged. The most natural way to
model this is to have the state field in the CPU struct be a
64 bit value, and simply have the AArch32 TCG code operate on
a pointer to its lower half.

For aarch64-linux-user the only registers we need to share like
this are the thread-local-storage ones. Widen their fields to
64 bits and provide the 64 bit reginfo struct to make them
visible in AArch64 state. Note that minor cleanup of the AArch64
system register encoding space means We can share the TPIDR_EL1
reginfo but need split encodings for TPIDR_EL0 and TPIDRRO_EL0.

Since we're touching almost every line in QEMU that uses the
c13_tls* fields in this patch anyway, we take the opportunity
to rename them in line with the standard ARM architectural names
for these registers.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NRichard Henderson <rth@twiddle.net>

Implement an initial minimal set of EL0-visible system registers:
 * NZCV
 * FPCR
 * FPSR
 * CTR_EL0
 * DCZID_EL0
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NRichard Henderson <rth@twiddle.net>
Reviewed-by: NPeter Crosthwaite <peter.crosthwaite@xilinx.com>

The cpregs APIs used by the decoder (get_arm_cp_reginfo() and
cp_access_ok()) currently take either a CPUARMState* or an ARMCPU*.
This is problematic for the A64 decoder, which doesn't pass the
environment pointer around everywhere the way the 32 bit decoder
does. Adjust the parameters these functions take so that we can
copy only the relevant info from the CPUARMState into the
DisasContext and then use that.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NRichard Henderson <rth@twiddle.net>

Update the generic cpreg support code to also handle AArch64:
AArch64-visible registers coexist in the same hash table with
AArch32-visible ones, with a bit in the hash key distinguishing
them.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NPeter Crosthwaite <peter.crosthwaite@xilinx.com>

The information which AArch32 holds in the FPSCR is split for
AArch64 into two logically distinct registers, FPSR and FPCR.
Since they are carefully arranged to use non-overlapping bits,
we leave the underlying state in the same place, and provide
accessor functions which just update the appropriate bits
via vfp_get_fpscr() and vfp_set_fpscr().
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NRichard Henderson <rth@twiddle.net>

The env->pstate field is a little odd since it doesn't strictly
speaking represent an architectural register. However it's convenient
for QEMU to use it to hold the various PSTATE architectural bits
in the same format the architecture specifies for SPSR registers
(since this is the same format the kernel uses for signal handlers
and the KVM register). Add some structure to how we deal with it:
 * document what env->pstate is
 * add some #defines for various bits in it
 * add helpers for reading/writing it taking account of caching
   of NZCV, and use them where appropriate
 * reset it on startup
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Message-id: 1385645602-18662-3-git-send-email-peter.maydell@linaro.org
Reviewed-by: NChristoffer Dall <christoffer.dall@linaro.org>