Paolo Bonzini [Tue, 22 May 2018 19:17:43 +0000 (21:17 +0200)]
ppc: move at24c to its own CONFIG_ symbol
AT24c EEPROM is currently gated by CONFIG_I2C, and as such it is
being included in all emulators that use I2C, even if they do not
really need it. Separate it and, since it was added for the e500
machines, add it to qemu-system-ppc and qemu-system-ppc64.
Cleber Rosa [Thu, 4 Oct 2018 16:18:47 +0000 (12:18 -0400)]
docs/devel/testing.rst: add missing newlines after code block
The line immediate following a ".. code::" block is considered
to contains arguments to the "code directive". The lack of a
new line gives me during at parse time:
testing.rst:63: (ERROR/3) Error in "code" directive:
maximum 1 argument(s) allowed, 3 supplied.
.. code::
make check-unit V=1
testing.rst:120: (ERROR/3) Error in "code" directive:
maximum 1 argument(s) allowed, 3 supplied.
.. code::
make check-qtest V=1
Let's add the missing newlines, both for consistency and to
avoid the parsing errors.
Peter Maydell [Thu, 25 Oct 2018 16:41:03 +0000 (17:41 +0100)]
Merge remote-tracking branch 'remotes/riscv/tags/riscv-for-master-3.1-sf0' into staging
First RISC-V Patch Set for the 3.1 Soft Freeze
This pull request contains a handful of patches that have been floating
around various trees for a while but haven't made it upstream. These
patches all appear quite safe. They're all somewhat independent from
each other:
* One refactors our IRQ management function to allow multiple interrupts
to be raised an once. This patch has no functional difference.
* Cleaning up the op_helper/cpu_helper split. This patch has no
functional difference.
* Updates to various constants to keep them in sync with the latest ISA
specification and to remove some non-standard bits that snuck in.
* A fix for a memory leak in the PLIC driver.
* A fix to our device tree handling to avoid provinging a NULL string.
I've given this my standard test: building the port, booting a Fedora
root filesytem on the latest Linux tag, and then shutting down that
image. Essentially I'm just following the QEMU RISC-V wiki page's
instructions. Everything looks fine here.
We have a lot more outstanding patches so I'll definately be submitting
another PR for the soft freeze.
# gpg: Signature made Wed 17 Oct 2018 21:17:52 BST
# gpg: using RSA key EF4CA1502CCBAB41
# gpg: Good signature from "Palmer Dabbelt <[email protected]>"
# gpg: aka "Palmer Dabbelt <[email protected]>"
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 00CE 76D1 8349 60DF CE88 6DF8 EF4C A150 2CCB AB41
* remotes/riscv/tags/riscv-for-master-3.1-sf0:
RISC-V: Don't add NULL bootargs to device-tree
RISC-V: Add missing free for plic_hart_config
RISC-V: Update CSR and interrupt definitions
RISC-V: Move non-ops from op_helper to cpu_helper
RISC-V: Allow setting and clearing multiple irqs
Peter Maydell [Wed, 24 Oct 2018 21:08:42 +0000 (22:08 +0100)]
Merge remote-tracking branch 'remotes/berrange/tags/qcrypto-next-pull-request' into staging
Improve performance of XTS cipher mode impl
The XTS cipher mode performance is approximately doubled and test
coverage is improved.
# gpg: Signature made Wed 24 Oct 2018 19:05:08 BST
# gpg: using RSA key BE86EBB415104FDF
# gpg: Good signature from "Daniel P. Berrange <[email protected]>"
# gpg: aka "Daniel P. Berrange <[email protected]>"
# Primary key fingerprint: DAF3 A6FD B26B 6291 2D0E 8E3F BE86 EBB4 1510 4FDF
* remotes/berrange/tags/qcrypto-next-pull-request:
crypto: add testing for unaligned buffers with XTS cipher mode
crypto: refactor XTS cipher mode test suite
crypto: annotate xts_tweak_encdec as inlineable
crypto: convert xts_mult_x to use xts_uint128 type
crypto: convert xts_tweak_encdec to use xts_uint128 type
crypto: introduce a xts_uint128 data type
crypto: remove code duplication in tweak encrypt/decrypt
crypto: expand algorithm coverage for cipher benchmark
The new type is designed to allow use of 64-bit arithmetic instead
of operating 1-byte at a time. The following patches will use this to
improve performance.
crypto: remove code duplication in tweak encrypt/decrypt
The tweak encrypt/decrypt functions are identical except for the
comments, so can be merged. Profiling data shows that the compiler is
in fact already merging the two merges in the object files.
Peter Maydell [Wed, 24 Oct 2018 15:31:40 +0000 (16:31 +0100)]
Merge remote-tracking branch 'remotes/amarkovic/tags/mips-queue-oct-2018-part-2-v2' into staging
MIPS queue for October 2018 - part 2 - v2
# gpg: Signature made Wed 24 Oct 2018 14:22:54 BST
# gpg: using RSA key D4972A8967F75A65
# gpg: Good signature from "Aleksandar Markovic <[email protected]>"
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 8526 FBF1 5DA3 811F 4A01 DD75 D497 2A89 67F7 5A65
* remotes/amarkovic/tags/mips-queue-oct-2018-part-2-v2: (33 commits)
target/mips: Fix decoding of ALIGN and DALIGN instructions
target/mips: Fix the title of translate.c
linux-user/mips: Recognize the R5900 CPU model
target/mips: Define the R5900 CPU
tests/tcg/mips: Add tests for R5900 DIVU1
tests/tcg/mips: Add tests for R5900 DIV1
tests/tcg/mips: Add tests for R5900 MTLO1 and MTHI1
tests/tcg/mips: Add tests for R5900 MFLO1 and MFHI1
tests/tcg/mips: Add tests for R5900 three-operand MULTU1
tests/tcg/mips: Add tests for R5900 three-operand MULT1
tests/tcg/mips: Add tests for R5900 three-operand MULTU
tests/tcg/mips: Add tests for R5900 three-operand MULT
target/mips: Make R5900 DMULT[U], DDIV[U], LL[D] and SC[D] user only
target/mips: Support R5900 MOVN, MOVZ and PREF instructions from MIPS IV
target/mips: Support R5900 DIV1 and DIVU1 instructions
target/mips: Support R5900 MFLO1, MTLO1, MFHI1 and MTHI1 instructions
target/mips: Support R5900 three-operand MULT1 and MULTU1 instructions
target/mips: Support R5900 three-operand MULT and MULTU instructions
target/mips: Add a placeholder for R5900 MMI3 instruction subclass
target/mips: Add a placeholder for R5900 MMI2 instruction subclass
...
Peter Maydell [Wed, 24 Oct 2018 15:01:05 +0000 (16:01 +0100)]
Merge remote-tracking branch 'remotes/huth-gitlab/tags/pull-request-2018-10-24' into staging
- Disable migration-test with TCG on s390x (since there are known problems)
- Small Makefile improvements
- More modern shell scripting changes (use $() instead of ``)
- Add a configure option to disable AVX2
* remotes/huth-gitlab/tags/pull-request-2018-10-24:
configure: Provide option to explicitly disable AVX2
po/Makefile: Modern shell scripting (use $() instead of ``)
debian-bootstrap.pre: Modern shell scripting (use $() instead of ``)
configs: Add a CONFIG_SMC37C669 switch for the "smc37c669-superio" device
hw/core: Move null-machine into the common-obj list
tests/migration-test: Disable s390x test when running with TCG
Fredrik Noring [Sun, 21 Oct 2018 15:44:58 +0000 (17:44 +0200)]
linux-user/mips: Recognize the R5900 CPU model
This kind of ELF for the R5900 relies on an IEEE 754-1985 compliant FPU.
The R5900 FPU hardware is noncompliant and it is therefore emulated in
software by the Linux kernel. QEMU emulates a compliant FPU accordingly.
Fredrik Noring [Sun, 21 Oct 2018 15:44:46 +0000 (17:44 +0200)]
target/mips: Define the R5900 CPU
The primary purpose of this change is to support programs compiled by
GCC for the R5900 target and thereby run R5900 Linux distributions, for
example Gentoo.
GCC in version 7.3, by itself, by inspection of the GCC source code
and inspection of the generated machine code, for the R5900 target,
only emits two instructions that are specific to the R5900: the three-
operand MULT and MULTU. GCC and libc also emit certain MIPS III
instructions that are not part of the R5900 ISA. They are normally
trapped and emulated by the Linux kernel, and therefore need to be
treated accordingly by QEMU.
A program compiled by GCC is taken to mean source code compiled by GCC
under the restrictions above. One can, with the apparent limitations,
with a bit of effort obtain a fully functioning operating system such
as R5900 Gentoo. Strictly speaking, programs need not be compiled by
GCC to make use of this change.
Instructions and other facilities of the R5900 not implemented by this
change are intended to signal provisional exceptions. One such example
is the FPU that is not compliant with IEEE 754-1985 in system mode. It
is therefore provisionally disabled. In user space the FPU is trapped
and emulated by IEEE 754-1985 compliant software in the kernel, and
this is handled accordingly by QEMU. Another example is the 93
multimedia instructions specific to the R5900 that generate provisional
reserved instruction exception signals.
One of the benefits of running a Linux distribution under QEMU is that
programs can be compiled with a native compiler, where the host and
target are the same, as opposed to a cross-compiler, where they are
not the same. This is especially important in cases where the target
hardware does not have the resources to run a native compiler.
Problems with cross-compilation are often related to host and target
differences in integer sizes, pointer sizes, endianness, machine code,
ABI, etc. Sometimes cross-compilation is not even supported by the
build script for a given package. One effective way to avoid those
problems is to replace the cross-compiler with a native compiler. This
change of compilation methods does not resolve the inherent problems
with cross-compilation.
The native compiler naturally replaces the cross-compiler, because one
typically uses one or the other, and preferably the native compiler
when the circumstances admit this. The native compiler is also a good
test case for the R5900 QEMU user mode. Additionally, Gentoo is well-
known for compiling and installing its packages from sources.
This change has been tested with Gentoo compiled for R5900, including
native compilation of several packages under QEMU.
Fredrik Noring [Sun, 21 Oct 2018 15:40:18 +0000 (17:40 +0200)]
target/mips: Make R5900 DMULT[U], DDIV[U], LL[D] and SC[D] user only
The Linux kernel traps certain reserved instruction exceptions to
emulate the corresponding instructions. QEMU plays the role of the
kernel in user mode, so those traps are emulated by accepting the
instructions.
This change adds the function check_insn_opc_user_only to signal a
reserved instruction exception for flagged CPUs in QEMU system mode.
The MIPS III instructions DMULT[U], DDIV[U], LL[D] and SC[D] are not
implemented in R5900 hardware. They are trapped and emulated by the
Linux kernel and, accordingly, therefore QEMU user only instructions.
Fredrik Noring [Sun, 21 Oct 2018 15:38:21 +0000 (17:38 +0200)]
target/mips: Support R5900 three-operand MULT and MULTU instructions
The three-operand MULT and MULTU are the only R5900-specific
instructions emitted by GCC 7.3. The R5900 also implements the three-
operand MADD and MADDU instructions, but they are omitted in QEMU for
now since they are absent in programs compiled by current GCC versions.
Likewise, the R5900-specific pipeline 1 instruction variants MULT1,
MULTU1, DIV1, DIVU1, MADD1, MADDU1, MFHI1, MFLO1, MTHI1 and MTLO1
are omitted here as well.
Fredrik Noring [Sun, 21 Oct 2018 15:31:26 +0000 (17:31 +0200)]
target/mips: Define R5900 ISA, MMI ASE, and R5900 CPU preprocessor constants
The R5900 implements the 64-bit MIPS III instruction set except
DMULT, DMULTU, DDIV, DDIVU, LL, SC, LLD and SCD. The MIPS IV
instructions MOVN, MOVZ and PREF are implemented. It has the
R5900-specific three-operand instructions MADD, MADDU, MULT and
MULTU as well as pipeline 1 versions MULT1, MULTU1, DIV1, DIVU1,
MADD1, MADDU1, MFHI1, MFLO1, MTHI1 and MTLO1. A set of 93 128-bit
multimedia instructions specific to the R5900 is also implemented.
The Toshiba TX System RISC TX79 Core Architecture manual:
https://wiki.qemu.org/File:C790.pdf
describes the C790 processor that is a follow-up to the R5900. There
are a few notable differences in that the R5900 FPU
- is not IEEE 754-1985 compliant,
- does not implement double format, and
- its machine code is nonstandard.
Peter Maydell [Wed, 24 Oct 2018 09:49:14 +0000 (10:49 +0100)]
Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20181024' into staging
target-arm queue:
* ssi-sd: Make devices picking up backends unavailable with -device
* Add support for VCPU event states
* Move towards making ID registers the source of truth for
whether a guest CPU implements a feature, rather than having
parallel ID registers and feature bit flags
* Implement various HCR hypervisor trap/config bits
* Get IL bit correct for v7 syndrome values
* Report correct syndrome for FP/SIMD traps to Hyp mode
* hw/arm/boot: Increase compliance with kernel arm64 boot protocol
* Refactor A32 Neon to use generic vector infrastructure
* Fix a bug in A32 VLD2 "(multiple 2-element structures)" insn
* net: cadence_gem: Report features correctly in ID register
* Avoid some unnecessary TLB flushes on TTBR register writes
* remotes/pmaydell/tags/pull-target-arm-20181024: (44 commits)
target/arm: Only flush tlb if ASID changes
target/arm: Remove writefn from TTBR0_EL3
net: cadence_gem: Announce 64bit addressing support
net: cadence_gem: Announce availability of priority queues
target/arm: Reorg NEON VLD/VST single element to one lane
target/arm: Promote consecutive memory ops for aa32
target/arm: Reorg NEON VLD/VST all elements
target/arm: Use gvec for NEON VLD all lanes
target/arm: Use gvec for NEON_3R_VTST_VCEQ, NEON_3R_VCGT, NEON_3R_VCGE
target/arm: Use gvec for NEON_3R_VML
target/arm: Use gvec for VSRI, VSLI
target/arm: Use gvec for VSRA
target/arm: Use gvec for VSHR, VSHL
target/arm: Use gvec for NEON_3R_VMUL
target/arm: Use gvec for NEON_2RM_VMN, NEON_2RM_VNEG
target/arm: Use gvec for NEON_3R_VADD_VSUB insns
target/arm: Use gvec for NEON_3R_LOGIC insns
target/arm: Use gvec for NEON VMOV, VMVN, VBIC & VORR (immediate)
target/arm: Use gvec for NEON VDUP
target/arm: Mark some arrays const
...
net: cadence_gem: Announce availability of priority queues
Announce the availability of the various priority queues.
This fixes an issue where guest kernels would miss to
configure secondary queues due to inproper feature bits.
target/arm: Promote consecutive memory ops for aa32
For a sequence of loads or stores from a single register,
little-endian operations can be promoted to an 8-byte op.
This can reduce the number of operations by a factor of 8.
Instead of shifts and masks, use direct loads and stores from the neon
register file. Mirror the iteration structure of the ARM pseudocode
more closely. Correct the parameters of the VLD2 A2 insn.
Note that this includes a bugfix for handling of the insn
"VLD2 (multiple 2-element structures)" -- we were using an
incorrect stride value.
target/arm: Promote consecutive memory ops for aa64
For a sequence of loads or stores from a single register,
little-endian operations can be promoted to an 8-byte op.
This can reduce the number of operations by a factor of 8.
hw/arm/boot: Increase compliance with kernel arm64 boot protocol
"The Image must be placed text_offset bytes from a 2MB aligned base
address anywhere in usable system RAM and called there."
For the virt board, we write our startup bootloader at the very
bottom of RAM, so that bit can't be used for the image. To avoid
overlap in case the image requests to be loaded at an offset
smaller than our bootloader, we increment the load offset to the
next 2MB.
Peter Maydell [Wed, 24 Oct 2018 06:50:18 +0000 (07:50 +0100)]
target/arm: Report correct syndrome for FP/SIMD traps to Hyp mode
For traps of FP/SIMD instructions to AArch32 Hyp mode, the syndrome
provided in HSR has more information than is reported to AArch64.
Specifically, there are extra fields TA and coproc which indicate
whether the trapped instruction was FP or SIMD. Add this extra
information to the syndromes we construct, and mask it out when
taking the exception to AArch64.
Peter Maydell [Wed, 24 Oct 2018 06:50:18 +0000 (07:50 +0100)]
target/arm: Get IL bit correct for v7 syndrome values
For the v7 version of the Arm architecture, the IL bit in
syndrome register values where the field is not valid was
defined to be UNK/SBZP. In v8 this is RES1, which is what
QEMU currently implements. Handle the desired v7 behaviour
by squashing the IL bit for the affected cases:
* EC == EC_UNCATEGORIZED
* prefetch aborts
* data aborts where ISV is 0
(The fourth case listed in the v8 Arm ARM DDI 0487C.a in
section G7.2.70, "illegal state exception", can't happen
on a v7 CPU.)
Peter Maydell [Wed, 24 Oct 2018 06:50:18 +0000 (07:50 +0100)]
target/arm: Implement HCR.PTW
If the HCR_EL2 PTW virtualizaiton configuration register bit
is set, then this means that a stage 2 Permission fault must
be generated if a stage 1 translation table access is made
to an address that is mapped as Device memory in stage 2.
Implement this.
Peter Maydell [Wed, 24 Oct 2018 06:50:17 +0000 (07:50 +0100)]
target/arm: Implement HCR.VI and VF
The HCR_EL2 VI and VF bits are supposed to track whether there is
a pending virtual IRQ or virtual FIQ. For QEMU we store the
pending VIRQ/VFIQ status in cs->interrupt_request, so this means:
* if the register is read we must get these bit values from
cs->interrupt_request
* if the register is written then we must write the bit
values back into cs->interrupt_request
Peter Maydell [Wed, 24 Oct 2018 06:50:17 +0000 (07:50 +0100)]
target/arm: ISR_EL1 bits track virtual interrupts if IMO/FMO set
The A/I/F bits in ISR_EL1 should track the virtual interrupt
status, not the physical interrupt status, if the associated
HCR_EL2.AMO/IMO/FMO bit is set. Implement this, rather than
always showing the physical interrupt status.
We don't currently implement anything to do with external
aborts, so this applies only to the I and F bits (though it
ought to be possible for the outer guest to present a virtual
external abort to the inner guest, even if QEMU doesn't
emulate physical external aborts, so there is missing
functionality in this area).
Peter Maydell [Wed, 24 Oct 2018 06:50:17 +0000 (07:50 +0100)]
target/arm: Implement HCR.DC
The HCR.DC virtualization configuration register bit has the
following effects:
* SCTLR.M behaves as if it is 0 for all purposes except
direct reads of the bit
* HCR.VM behaves as if it is 1 for all purposes except
direct reads of the bit
* the memory type produced by the first stage of the EL1&EL0
translation regime is Normal Non-Shareable,
Inner Write-Back Read-Allocate Write-Allocate,
Outer Write-Back Read-Allocate Write-Allocate.
Peter Maydell [Wed, 24 Oct 2018 06:50:17 +0000 (07:50 +0100)]
target/arm: Implement HCR.FB
The HCR.FB virtualization configuration register bit requests that
TLB maintenance, branch predictor invalidate-all and icache
invalidate-all operations performed in NS EL1 should be upgraded
from "local CPU only to "broadcast within Inner Shareable domain".
For QEMU we NOP the branch predictor and icache operations, so
we only need to upgrade the TLB invalidates:
AArch32 TLBIALL, TLBIMVA, TLBIASID, DTLBIALL, DTLBIMVA, DTLBIASID,
ITLBIALL, ITLBIMVA, ITLBIASID, TLBIMVAA, TLBIMVAL, TLBIMVAAL
AArch64 TLBI VMALLE1, TLBI VAE1, TLBI ASIDE1, TLBI VAAE1,
TLBI VALE1, TLBI VAALE1
Peter Maydell [Wed, 24 Oct 2018 06:50:17 +0000 (07:50 +0100)]
target/arm: Make switch_mode() file-local
The switch_mode() function is defined in target/arm/helper.c and used
only in that file and nowhere else, so we can make it file-local
rather than global.
Peter Maydell [Wed, 24 Oct 2018 06:50:17 +0000 (07:50 +0100)]
target/arm: Improve debug logging of AArch32 exception return
For AArch32, exception return happens through certain kinds
of CPSR write. We don't currently have any CPU_LOG_INT logging
of these events (unlike AArch64, where we log in the ERET
instruction). Add some suitable logging.
This will log exception returns like this:
Exception return from AArch32 hyp to usr PC 0x80100374
paralleling the existing logging in the exception_return
helper for AArch64 exception returns:
Exception return from AArch64 EL2 to AArch64 EL0 PC 0x8003045c
Exception return from AArch64 EL2 to AArch32 EL0 PC 0x8003045c
(Note that an AArch32 exception return can only be
AArch32->AArch32, never to AArch64.)
projects / qemu.git / log