aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-02-14target/arm: Correctly implement ACTLR2, HACTLR2vmid16Peter Maydell
The ACTLR2 and HACTLR2 AArch32 system registers didn't exist in ARMv7 or the original ARMv8. They were later added as optional registers, whose presence is signaled by the ID_MMFR4.AC2 field. From ARMv8.2 they are mandatory (ie ID_MMFR4.AC2 must be non-zero). We implemented HACTLR2 in commit 0e0456ab8895a5e85, but we incorrectly made it exist for all v8 CPUs, and we didn't implement ACTLR2 at all. Sort this out by implementing both registers only when they are supposed to exist, and setting the ID_MMFR4 bit for -cpu max. Note that this removes HACTLR2 from our Cortex-A53, -A47 and -A72 CPU models; this is correct, because those CPUs do not implement this register. Fixes: 0e0456ab8895a5e85 Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-14target/arm: Use FIELD_EX32 for testing 32-bit fieldsPeter Maydell
Cut-and-paste errors mean we're using FIELD_EX64() to extract fields from some 32-bit ID register fields. Use FIELD_EX32() instead. (This makes no difference in behaviour, it's just more consistent.) Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-14target/arm: Use isar_feature function for testing AA32HPD featurePeter Maydell
Now we have moved ID_MMFR4 into the ARMISARegisters struct, we can define and use an isar_feature for the presence of the ARMv8.2-AA32HPD feature, rather than open-coding the test. While we're here, correct a comment typo which missed an 'A' from the feature name. Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-14target/arm: Test correct register in aa32_pan and aa32_ats1e1 checksPeter Maydell
The isar_feature_aa32_pan and isar_feature_aa32_ats1e1 functions are supposed to be testing fields in ID_MMFR3; but a cut-and-paste error meant we were looking at MVFR0 instead. Fix the functions to look at the right register; this requires us to move at least id_mmfr3 to the ARMISARegisters struct; we choose to move all the ID_MMFRn registers for consistency. Fixes: 3d6ad6bb466f Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-14target/arm: Correct handling of PMCR_EL0.LC bitPeter Maydell
The LC bit in the PMCR_EL0 register is supposed to be: * read/write * RES1 on an AArch64-only implementation * an architecturally UNKNOWN value on reset (and use of LC==0 by software is deprecated). We were implementing it incorrectly as read-only always zero, though we do have all the code needed to test it and behave accordingly. Instead make it a read-write bit which resets to 1 always, which satisfies all the architectural requirements above. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-14target/arm: Correct definition of PMCRDPPeter Maydell
The PMCR_EL0.DP bit is bit 5, which is 0x20, not 0x10. 0x10 is 'X'. Correct our #define of PMCRDP and add the missing PMCRX. We do have the correct behaviour for handling the DP bit being set, so this fixes a guest-visible bug. Fixes: 033614c47de Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-14target/arm: Provide ARMv8.4-PMU in '-cpu max'Peter Maydell
Set the ID register bits to provide ARMv8.4-PMU (and implicitly also ARMv8.1-PMU) in the 'max' CPU. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> --- v1->v2: use FIELD_DP64 for 64-bit idreg
2020-02-14target/arm: Implement ARMv8.4-PMU extensionPeter Maydell
The ARMv8.4-PMU extension adds: * one new required event, STALL * one new system register PMMIR_EL1 (There are also some more L1-cache related events, but since we don't implement any cache we don't provide these, in the same way we don't provide the base-PMUv3 cache events.) The STALL event "counts every attributable cycle on which no attributable instruction or operation was sent for execution on this PE". QEMU doesn't stall in this sense, so this is another always-reads-zero event. The PMMIR_EL1 register is a read-only register providing implementation-specific information about the PMU; currently it has only one field, SLOTS, which defines behaviour of the STALL_SLOT PMU event. Since QEMU doesn't implement the STALL_SLOT event, we can validly make the register read zero. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-14target/arm: Implement ARMv8.1-PMU extensionPeter Maydell
The ARMv8.1-PMU extension requires: * the evtCount field in PMETYPER<n>_EL0 is 16 bits, not 10 * MDCR_EL2.HPMD allows event counting to be disabled at EL2 * two new required events, STALL_FRONTEND and STALL_BACKEND * ID register bits in ID_AA64DFR0_EL1 and ID_DFR0 We already implement the 16-bit evtCount field and the HPMD bit, so all that is missing is the two new events: STALL_FRONTEND "counts every cycle counted by the CPU_CYCLES event on which no operation was issued because there are no operations available to issue to this PE from the frontend" STALL_BACKEND "counts every cycle counted by the CPU_CYCLES event on which no operation was issued because the backend is unable to accept any available operations from the frontend" QEMU never stalls in this sense, so our implementation is trivial: always return a zero count. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-14target/arm: Read debug-related ID registers from KVMPeter Maydell
Now we have isar_feature test functions that look at fields in the ID_AA64DFR0_EL1 and ID_DFR0 ID registers, add the code that reads these register values from KVM so that the checks behave correctly when we're using KVM. No isar_feature function tests ID_AA64DFR1_EL1 or DBGDIDR yet, but we add it to maintain the invariant that every field in the ARMISARegisters struct is populated for a KVM CPU and can be relied on. This requirement isn't actually written down yet, so add a note to the relevant comment. Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-14target/arm: Move DBGDIDR into ARMISARegistersPeter Maydell
We're going to want to read the DBGDIDR register from KVM in a subsequent commit, which means it needs to be in the ARMISARegisters sub-struct. Move it. Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-14target/arm: Stop assuming DBGDIDR always existsPeter Maydell
The AArch32 DBGDIDR defines properties like the number of breakpoints, watchpoints and context-matching comparators. On an AArch64 CPU, the register may not even exist if AArch32 is not supported at EL1. Currently we hard-code use of DBGDIDR to identify the number of breakpoints etc; this works for all our TCG CPUs, but will break if we ever add an AArch64-only CPU. We also have an assert() that the AArch32 and AArch64 registers match, which currently works only by luck for KVM because we don't populate either of these ID registers from the KVM vCPU and so they are both zero. Clean this up so we have functions for finding the number of breakpoints, watchpoints and context comparators which look in the appropriate ID register. This allows us to drop the "check that AArch64 and AArch32 agree on the number of breakpoints etc" asserts: * we no longer look at the AArch32 versions unless that's the right place to be looking * it's valid to have a CPU (eg AArch64-only) where they don't match * we shouldn't have been asserting the validity of ID registers in a codepath used with KVM anyway Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-14target/arm: Add _aa64_ and _any_ versions of pmu_8_1 isar checksPeter Maydell
Add the 64-bit version of the "is this a v8.1 PMUv3?" ID register check function, and the _any_ version that checks for either AArch32 or AArch64 support. We'll use this in a later commit. We don't (yet) do any isar_feature checks on ID_AA64DFR1_EL1, but we move id_aa64dfr1 into the ARMISARegisters struct with id_aa64dfr0, for consistency. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> --- v1->v2: * fix use of FIELD_EX32 in _aa64_ function
2020-02-14target/arm: Define an aa32_pmu_8_1 isar feature test functionPeter Maydell
Instead of open-coding a check on the ID_DFR0 PerfMon ID register field, create a standardly-named isar_feature for "does AArch32 have a v8.1 PMUv3" and use it. This entails moving the id_dfr0 field into the ARMISARegisters struct. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-14target/arm: Use FIELD macros for clearing ID_DFR0 PERFMON fieldPeter Maydell
We already define FIELD macros for ID_DFR0, so use them in the one place where we're doing direct bit value manipulation. Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> --- We have lots of this non-FIELD style in the code, of course; I change this one purely because it otherwise looks a bit odd sat next to the ID_AA64DFR0 line that was changed in the previous patch...
2020-02-14target/arm: Add and use FIELD definitions for ID_AA64DFR0_EL1Peter Maydell
Add FIELD() definitions for the ID_AA64DFR0_EL1 and use them where we currently have hard-coded bit values. Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> --- v1->v2: use FIELD_EX64/FIELD_DP64 for 64-bit ID register
2020-02-14target/arm: Factor out PMU register definitionsPeter Maydell
Pull the code that defines the various PMU registers out into its own function, matching the pattern we have already for the debug registers. Apart from one style fix to a multi-line comment, this is purely movement of code with no changes to it. Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-14target/arm: Define and use any_predinv isar_feature testPeter Maydell
Instead of open-coding "ARM_FEATURE_AARCH64 ? aa64_predinv: aa32_predinv", define and use an any_predinv isar_feature test function. Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-14target/arm: Add isar_feature_any_fp16 and document naming/usage conventionsPeter Maydell
Our current usage of the isar_feature feature tests almost always uses an _aa32_ test when the code path is known to be AArch32 specific and an _aa64_ test when the code path is known to be AArch64 specific. There is just one exception: in the vfp_set_fpscr helper we check aa64_fp16 to determine whether the FZ16 bit in the FP(S)CR exists, but this code is also used for AArch32. There are other places in future where we're likely to want a general "does this feature exist for either AArch32 or AArch64" check (typically where architecturally the feature exists for both CPU states if it exists at all, but the CPU might be AArch32-only or AArch64-only, and so only have one set of ID registers). Introduce a new category of isar_feature_* functions: isar_feature_any_foo() should be tested when what we want to know is "does this feature exist for either AArch32 or AArch64", and always returns the logical OR of isar_feature_aa32_foo() and isar_feature_aa64_foo(). Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-14target/arm: Check aa32_pan in take_aarch32_exception(), not aa64_panPeter Maydell
In take_aarch32_exception(), we know we are dealing with a CPU that has AArch32, so the right isar_feature test is aa32_pan, not aa64_pan. Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-14target/arm: Add _aa32_ to isar_feature functions testing 32-bit ID registersPeter Maydell
Enforce a convention that an isar_feature function that tests a 32-bit ID register always has _aa32_ in its name, and one that tests a 64-bit ID register always has _aa64_ in its name. We already follow this except for three cases: thumb_div, arm_div and jazelle, which all need _aa32_ adding. (As noted in the comment, isar_feature_aa32_fp16_arith() is an exception in that it currently tests ID_AA64PFR0_EL1, but will switch to MVFR1 once we've properly implemented FP16 for AArch32.) Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> --- v1->v2: fixed up new use of isar_feature_jazelle() in aarch32_cpsr_valid_mask()
2020-02-14Merge remote-tracking branch ↵Peter Maydell
'remotes/pmaydell/tags/pull-target-arm-20200213' into staging target-arm queue: * i.MX: Fix inverted sense of register bits in watchdog timer * i.MX: Add support for WDT on i.MX6 * arm/virt: cleanups to ACPI tables * Implement ARMv8.1-VMID16 extension * Implement ARMv8.1-PAN * Implement ARMv8.2-UAO * Implement ARMv8.2-ATS1E1 * ast2400/2500/2600: Wire up EHCI controllers * hw/char/exynos4210_uart: Fix memleaks in exynos4210_uart_init * hw/arm/raspi: Clean up the board code # gpg: Signature made Thu 13 Feb 2020 14:40:34 GMT # gpg: using RSA key E1A5C593CD419DE28E8315CF3C2525ED14360CDE # gpg: issuer "peter.maydell@linaro.org" # gpg: Good signature from "Peter Maydell <peter.maydell@linaro.org>" [ultimate] # gpg: aka "Peter Maydell <pmaydell@gmail.com>" [ultimate] # gpg: aka "Peter Maydell <pmaydell@chiark.greenend.org.uk>" [ultimate] # Primary key fingerprint: E1A5 C593 CD41 9DE2 8E83 15CF 3C25 25ED 1436 0CDE * remotes/pmaydell/tags/pull-target-arm-20200213: (46 commits) target/arm: Implement ARMv8.1-VMID16 extension hw/arm/raspi: Extract the cores count from the board revision hw/arm/raspi: Use a unique raspi_machine_class_init() method hw/arm/raspi: Extract the board model from the board revision hw/arm/raspi: Set default RAM size to size encoded in board revision hw/arm/raspi: Let class_init() directly call raspi_machine_init() hw/arm/raspi: Make board_rev a field of RaspiMachineClass hw/arm/raspi: Make machines children of abstract RaspiMachineClass hw/arm/raspi: Trivial code movement hw/arm/raspi: Extract the processor type from the board revision hw/arm/raspi: Extract the RAM size from the board revision hw/arm/raspi: Extract the version from the board revision hw/arm/raspi: Correct the board descriptions hw/arm/raspi: Use BCM2708 machine type with pre Device Tree kernels hw/char/exynos4210_uart: Fix memleaks in exynos4210_uart_init hw/arm: ast2600: Wire up EHCI controllers hw/arm: ast2400/ast2500: Wire up EHCI controllers target/arm: Enable ARMv8.2-UAO in -cpu max target/arm: Implement UAO semantics target/arm: Update MSR access to UAO ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13Merge remote-tracking branch 'remotes/kraxel/tags/vga-20200213-pull-request' ↵Peter Maydell
into staging qxl: introduce hardware revision 5 # gpg: Signature made Thu 13 Feb 2020 09:06:14 GMT # gpg: using RSA key 4CB6D8EED3E87138 # gpg: Good signature from "Gerd Hoffmann (work) <kraxel@redhat.com>" [full] # gpg: aka "Gerd Hoffmann <gerd@kraxel.org>" [full] # gpg: aka "Gerd Hoffmann (private) <kraxel@gmail.com>" [full] # Primary key fingerprint: A032 8CFF B93A 17A7 9901 FE7D 4CB6 D8EE D3E8 7138 * remotes/kraxel/tags/vga-20200213-pull-request: qxl: introduce hardware revision 5 Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20200212' into stagingPeter Maydell
Fix breakpoint invalidation. Add support for tcg helpers with 7 arguments. Add support for gvec helpers with 5 arguments. # gpg: Signature made Thu 13 Feb 2020 00:21:34 GMT # gpg: using RSA key 7A481E78868B4DB6A85A05C064DF38E8AF7E215F # gpg: issuer "richard.henderson@linaro.org" # gpg: Good signature from "Richard Henderson <richard.henderson@linaro.org>" [full] # Primary key fingerprint: 7A48 1E78 868B 4DB6 A85A 05C0 64DF 38E8 AF7E 215F * remotes/rth/tags/pull-tcg-20200212: tcg: Add tcg_gen_gvec_5_ptr tcg: Add support for a helper with 7 arguments exec: flush CPU TB cache in breakpoint_invalidate Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13Merge remote-tracking branch 'remotes/kraxel/tags/usb-20200212-pull-request' ↵Peter Maydell
into staging usb: bugfixes # gpg: Signature made Wed 12 Feb 2020 20:57:44 GMT # gpg: using RSA key 4CB6D8EED3E87138 # gpg: Good signature from "Gerd Hoffmann (work) <kraxel@redhat.com>" [full] # gpg: aka "Gerd Hoffmann <gerd@kraxel.org>" [full] # gpg: aka "Gerd Hoffmann (private) <kraxel@gmail.com>" [full] # Primary key fingerprint: A032 8CFF B93A 17A7 9901 FE7D 4CB6 D8EE D3E8 7138 * remotes/kraxel/tags/usb-20200212-pull-request: uas: fix super speed bMaxPacketSize0 usb-host: wait for cancel complete Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13target/arm: Implement ARMv8.1-VMID16 extensionpull-target-arm-20200213Peter Maydell
The ARMv8.1-VMID16 extension extends the VMID from 8 bits to 16 bits: * the ID_AA64MMFR1_EL1.VMIDBits field specifies whether the VMID is 8 or 16 bits * the VMID field in VTTBR_EL2 is extended to 16 bits * VTCR_EL2.VS lets the guest specify whether to use the full 16 bits, or use the backwards-compatible 8 bits For QEMU implementing this is trivial: * we do not track VMIDs in TLB entries, so we never use the VMID field * we treat any write to VTTBR_EL2, not just a change to the VMID field bits, as a "possible VMID change" that causes us to throw away TLB entries, so that code doesn't need changing * we allow the guest to read/write the VTCR_EL2.VS bit already So all that's missing is the ID register part: report that we support VMID16 in our 'max' CPU. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20200210120146.17631-1-peter.maydell@linaro.org
2020-02-13hw/arm/raspi: Extract the cores count from the board revisionPhilippe Mathieu-Daudé
The count of ARM cores is encoded in the board revision. Add a helper to extract the number of cores, and use it. This will be helpful when we add the Raspi0/1 that have a single core. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20200208165645.15657-14-f4bug@amsat.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> [PMM: tweaked commit message as suggested by Igor] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13hw/arm/raspi: Use a unique raspi_machine_class_init() methodPhilippe Mathieu-Daudé
With the exception of the ignore_memory_transaction_failures flag set for the raspi2, both machine_class_init() methods are now identical. Merge them to keep a unique method. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-id: 20200208165645.15657-13-f4bug@amsat.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13hw/arm/raspi: Extract the board model from the board revisionPhilippe Mathieu-Daudé
The board revision encode the model type. Add a helper to extract the model, and use it. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20200208165645.15657-12-f4bug@amsat.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13hw/arm/raspi: Set default RAM size to size encoded in board revisionPhilippe Mathieu-Daudé
We added a helper to extract the RAM size from the board revision, and made board_rev a field of RaspiMachineClass. The class_init() can now use the helper to extract from the board revision the board-specific amount of RAM. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20200208165645.15657-11-f4bug@amsat.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13hw/arm/raspi: Let class_init() directly call raspi_machine_init()Philippe Mathieu-Daudé
raspi_machine_init() access to board_rev via RaspiMachineClass. raspi2_init() and raspi3_init() do nothing. Call raspi_machine_init directly. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-id: 20200208165645.15657-10-f4bug@amsat.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13hw/arm/raspi: Make board_rev a field of RaspiMachineClassPhilippe Mathieu-Daudé
We want to have a common class_init(). The only value that matters (and changes) is the board revision. Pass the board_rev as class_data to class_init(). Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20200208165645.15657-9-f4bug@amsat.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13hw/arm/raspi: Make machines children of abstract RaspiMachineClassPhilippe Mathieu-Daudé
QOM'ify RaspiMachineState. Now machines inherit of RaspiMachineClass. Cc: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Acked-by: Igor Mammedov <imammedo@redhat.com> Message-id: 20200208165645.15657-8-f4bug@amsat.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13hw/arm/raspi: Trivial code movementPhilippe Mathieu-Daudé
There is no point in creating the SoC object before allocating the RAM. Move the call to keep all the SoC-related calls together. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Acked-by: Igor Mammedov <imammedo@redhat.com> Message-id: 20200208165645.15657-7-f4bug@amsat.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13hw/arm/raspi: Extract the processor type from the board revisionPhilippe Mathieu-Daudé
The board revision encode the processor type. Add a helper to extract the type, and use it. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20200208165645.15657-6-f4bug@amsat.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13hw/arm/raspi: Extract the RAM size from the board revisionPhilippe Mathieu-Daudé
The board revision encode the amount of RAM. Add a helper to extract the RAM size, and use it. Since the amount of RAM is fixed (it is impossible to physically modify to have more or less RAM), do not allow sizes different than the one anounced by the manufacturer. Acked-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20200208165645.15657-5-f4bug@amsat.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13hw/arm/raspi: Extract the version from the board revisionPhilippe Mathieu-Daudé
The board revision encode the board version. Add a helper to extract the version, and use it. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20200208165645.15657-4-f4bug@amsat.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13hw/arm/raspi: Correct the board descriptionsPhilippe Mathieu-Daudé
We hardcode the board revision as 0xa21041 for the raspi2, and 0xa02082 for the raspi3: 166 static void raspi_init(MachineState *machine, int version) 167 { ... 194 int board_rev = version == 3 ? 0xa02082 : 0xa21041; These revision codes are for the 2B and 3B models, see: https://www.raspberrypi.org/documentation/hardware/raspberrypi/revision-codes/README.md Correct the board description. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20200208165645.15657-3-f4bug@amsat.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13hw/arm/raspi: Use BCM2708 machine type with pre Device Tree kernelsPhilippe Mathieu-Daudé
When booting without device tree, the Linux kernels uses the $R1 register to determine the machine type. The list of values is registered at [1]. There are two entries for the Raspberry Pi: - https://www.arm.linux.org.uk/developer/machines/list.php?mid=3138 name: MACH_TYPE_BCM2708 value: 0xc42 (3138) status: Active, not mainlined date: 15 Oct 2010 - https://www.arm.linux.org.uk/developer/machines/list.php?mid=4828 name: MACH_TYPE_BCM2835 value: 4828 status: Active, mainlined date: 6 Dec 2013 QEMU always used the non-mainlined type MACH_TYPE_BCM2708. The value 0xc43 is registered to 'MX51_GGC' (processor i.MX51), and 0xc44 to 'Western Digital Sharespace NAS' (processor Marvell 88F5182). The Raspberry Pi foundation bootloader only sets the BCM2708 machine type, see [2] or [3]: 133 9: 134 mov r0, #0 135 ldr r1, =3138 @ BCM2708 machine id 136 ldr r2, atags @ ATAGS 137 bx r4 U-Boot only uses MACH_TYPE_BCM2708 (see [4]): 25 /* 26 * 2835 is a SKU in a series for which the 2708 is the first or primary SoC, 27 * so 2708 has historically been used rather than a dedicated 2835 ID. 28 * 29 * We don't define a machine type for bcm2709/bcm2836 since the RPi Foundation 30 * chose to use someone else's previously registered machine ID (3139, MX51_GGC) 31 * rather than obtaining a valid ID:-/ 32 * 33 * For the bcm2837, hopefully a machine type is not needed, since everything 34 * is DT. 35 */ While the definition MACH_BCM2709 with value 0xc43 was introduced in a commit described "Add 2709 platform for Raspberry Pi 2" out of the mainline Linux kernel, it does not seem used, and the platform is introduced with Device Tree support anyway (see [5] and [6]). Remove the unused values (0xc43 introduced in commit 1df7d1f9303aef "raspi: add raspberry pi 2 machine" and 0xc44 in commit bade58166f4 "raspi: Raspberry Pi 3 support"), keeping only MACH_TYPE_BCM2708. [1] https://www.arm.linux.org.uk/developer/machines/ [2] https://github.com/raspberrypi/tools/blob/920c7ed2e/armstubs/armstub7.S#L135 [3] https://github.com/raspberrypi/tools/blob/49719d554/armstubs/armstub7.S#L64 [4] https://gitlab.denx.de/u-boot/u-boot/blob/v2015.04/include/configs/rpi-common.h#L18 [5] https://github.com/raspberrypi/linux/commit/d9fac63adac#diff-6722037d79570df5b392a49e0e006573R526 [6] http://lists.infradead.org/pipermail/linux-rpi-kernel/2015-February/001268.html Cc: Zoltán Baldaszti <bztemail@gmail.com> Cc: Pekka Enberg <penberg@iki.fi> Cc: Stephen Warren <swarren@nvidia.com> Cc: Kshitij Soni <kshitij.soni@broadcom.com> Cc: Michael Chan <michael.chan@broadcom.com> Cc: Andrew Baumann <Andrew.Baumann@microsoft.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Niek Linnenbank <nieklinnenbank@gmail.com> Message-id: 20200208165645.15657-2-f4bug@amsat.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13hw/char/exynos4210_uart: Fix memleaks in exynos4210_uart_initChen Qun
It's easy to reproduce as follow: virsh qemu-monitor-command vm1 --pretty '{"execute": "device-list-properties", "arguments":{"typename":"exynos4210.uart"}}' ASAN shows memory leak stack: #1 0xfffd896d71cb in g_malloc0 (/lib64/libglib-2.0.so.0+0x571cb) #2 0xaaad270beee3 in timer_new_full /qemu/include/qemu/timer.h:530 #3 0xaaad270beee3 in timer_new /qemu/include/qemu/timer.h:551 #4 0xaaad270beee3 in timer_new_ns /qemu/include/qemu/timer.h:569 #5 0xaaad270beee3 in exynos4210_uart_init /qemu/hw/char/exynos4210_uart.c:677 #6 0xaaad275c8f4f in object_initialize_with_type /qemu/qom/object.c:516 #7 0xaaad275c91bb in object_new_with_type /qemu/qom/object.c:684 #8 0xaaad2755df2f in qmp_device_list_properties /qemu/qom/qom-qmp-cmds.c:152 Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Chen Qun <kuhn.chenqun@huawei.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20200213025603.149432-1-kuhn.chenqun@huawei.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13hw/arm: ast2600: Wire up EHCI controllersGuenter Roeck
Initialize EHCI controllers on AST2600 using the existing TYPE_PLATFORM_EHCI. After this change, booting ast2600-evb into Linux successfully instantiates a USB interface after the necessary changes are made to its devicetree files. ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver ehci-platform: EHCI generic platform driver ehci-platform 1e6a3000.usb: EHCI Host Controller ehci-platform 1e6a3000.usb: new USB bus registered, assigned bus number 1 ehci-platform 1e6a3000.usb: irq 25, io mem 0x1e6a3000 ehci-platform 1e6a3000.usb: USB 2.0 started, EHCI 1.00 usb usb1: Manufacturer: Linux 5.5.0-09825-ga0802f2d0ef5-dirty ehci_hcd usb 1-1: new high-speed USB device number 2 using ehci-platform Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Niek Linnenbank <nieklinnenbank@gmail.com> Message-id: 20200207174548.9087-1-linux@roeck-us.net Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13hw/arm: ast2400/ast2500: Wire up EHCI controllersGuenter Roeck
Initialize EHCI controllers on AST2400 and AST2500 using the existing TYPE_PLATFORM_EHCI. After this change, booting ast2500-evb into Linux successfully instantiates a USB interface. ehci-platform 1e6a3000.usb: EHCI Host Controller ehci-platform 1e6a3000.usb: new USB bus registered, assigned bus number 1 ehci-platform 1e6a3000.usb: irq 21, io mem 0x1e6a3000 ehci-platform 1e6a3000.usb: USB 2.0 started, EHCI 1.00 usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.05 usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: EHCI Host Controller Signed-off-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20200206183437.3979-1-linux@roeck-us.net Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13target/arm: Enable ARMv8.2-UAO in -cpu maxRichard Henderson
Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20200208125816.14954-21-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13target/arm: Implement UAO semanticsRichard Henderson
We need only override the current condition under which TBFLAG_A64.UNPRIV is set. Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20200208125816.14954-20-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13target/arm: Update MSR access to UAORichard Henderson
Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20200208125816.14954-19-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13target/arm: Add ID_AA64MMFR2_EL1Richard Henderson
Add definitions for all of the fields, up to ARMv8.5. Convert the existing RESERVED register to a full register. Query KVM for the value of the register for the host. Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20200208125816.14954-18-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13target/arm: Enable ARMv8.2-ATS1E1 in -cpu maxRichard Henderson
This includes enablement of ARMv8.1-PAN. Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20200208125816.14954-17-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13target/arm: Implement ATS1E1 system registersRichard Henderson
This is a minor enhancement over ARMv8.1-PAN. The *_PAN mmu_idx are used with the existing do_ats_write. Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20200208125816.14954-16-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13target/arm: Set PAN bit as required on exception entryRichard Henderson
The PAN bit is preserved, or set as per SCTLR_ELx.SPAN, plus several other conditions listed in the ARM ARM. Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20200208125816.14954-15-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13target/arm: Enforce PAN semantics in get_S1protRichard Henderson
If we have a PAN-enforcing mmu_idx, set prot == 0 if user_rw != 0. Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20200208125816.14954-14-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>