summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* target/arm: Move DBGDIDR into ARMISARegistersPeter Maydell2020-02-215-12/+12
| | | | | | | | | | 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> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20200214175116.9164-12-peter.maydell@linaro.org
* target/arm: Stop assuming DBGDIDR always existsPeter Maydell2020-02-214-19/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20200214175116.9164-11-peter.maydell@linaro.org
* target/arm: Add _aa64_ and _any_ versions of pmu_8_1 isar checksPeter Maydell2020-02-214-11/+25
| | | | | | | | | | | | | | | | 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> Message-id: 20200214175116.9164-10-peter.maydell@linaro.org
* target/arm: Define an aa32_pmu_8_1 isar feature test functionPeter Maydell2020-02-215-22/+28
| | | | | | | | | | | | 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> Message-id: 20200214175116.9164-9-peter.maydell@linaro.org
* target/arm: Use FIELD macros for clearing ID_DFR0 PERFMON fieldPeter Maydell2020-02-211-1/+1
| | | | | | | | | | 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> Message-id: 20200214175116.9164-8-peter.maydell@linaro.org
* target/arm: Add and use FIELD definitions for ID_AA64DFR0_EL1Peter Maydell2020-02-213-4/+14
| | | | | | | | | | 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> Message-id: 20200214175116.9164-7-peter.maydell@linaro.org
* target/arm: Factor out PMU register definitionsPeter Maydell2020-02-211-76/+82
| | | | | | | | | | | | | | 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> Message-id: 20200214175116.9164-6-peter.maydell@linaro.org
* target/arm: Define and use any_predinv isar_feature testPeter Maydell2020-02-212-8/+6Star
| | | | | | | | | | 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> Message-id: 20200214175116.9164-5-peter.maydell@linaro.org
* target/arm: Add isar_feature_any_fp16 and document naming/usage conventionsPeter Maydell2020-02-212-2/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | 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> Message-id: 20200214175116.9164-4-peter.maydell@linaro.org
* target/arm: Check aa32_pan in take_aarch32_exception(), not aa64_panPeter Maydell2020-02-211-1/+1
| | | | | | | | | 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> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20200214175116.9164-3-peter.maydell@linaro.org
* target/arm: Add _aa32_ to isar_feature functions testing 32-bit ID registersPeter Maydell2020-02-216-12/+21
| | | | | | | | | | | | | | | | | | 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> Message-id: 20200214175116.9164-2-peter.maydell@linaro.org
* target/arm: Split out aa64_va_parameter_tbi, aa64_va_parameter_tbidRichard Henderson2020-02-212-34/+37
| | | | | | | | | | | | | | | | | | For the purpose of rebuild_hflags_a64, we do not need to compute all of the va parameters, only tbi. Moreover, we can compute them in a form that is more useful to storing in hflags. This eliminates the need for aa64_va_parameter_both, so fold that in to aa64_va_parameter. The remaining calls to aa64_va_parameter are in get_phys_addr_lpae and in pauth_helper.c. This reduces the total cpu consumption of aa64_va_parameter in a kernel boot plus a kvm guest kernel boot from 3% to 0.5%. Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20200216194343.21331-5-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* target/arm: Remove ttbr1_valid check from get_phys_addr_lpaeRichard Henderson2020-02-211-5/+1Star
| | | | | | | | | | Now that aa64_va_parameters_both sets select based on the number of ranges in the regime, the ttbr1_valid check is redundant. Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20200216194343.21331-4-richard.henderson@linaro.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* target/arm: Fix select for aa64_va_parameters_bothRichard Henderson2020-02-211-22/+24
| | | | | | | | | Select should always be 0 for a regime with one range. Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20200216194343.21331-3-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* target/arm: Use bit 55 explicitly for pauthRichard Henderson2020-02-211-1/+2
| | | | | | | | | | | | The psuedocode in aarch64/functions/pac/auth/Auth and aarch64/functions/pac/strip/Strip always uses bit 55 for extfield and do not consider if the current regime has 2 ranges. Suggested-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20200216194343.21331-2-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* target/arm: Flush high bits of sve register after AdvSIMD INSRichard Henderson2020-02-211-0/+6
| | | | | | | | | Writes to AdvSIMD registers flush the bits above 128. Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20200214194643.23317-5-richard.henderson@linaro.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* target/arm: Flush high bits of sve register after AdvSIMD ZIP/UZP/TRNRichard Henderson2020-02-211-0/+1
| | | | | | | | | Writes to AdvSIMD registers flush the bits above 128. Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20200214194643.23317-4-richard.henderson@linaro.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* target/arm: Flush high bits of sve register after AdvSIMD TBL/TBXRichard Henderson2020-02-211-0/+1
| | | | | | | | | Writes to AdvSIMD registers flush the bits above 128. Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20200214194643.23317-3-richard.henderson@linaro.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* target/arm: Flush high bits of sve register after AdvSIMD EXTRichard Henderson2020-02-211-0/+1
| | | | | | | | | | Writes to AdvSIMD registers flush the bits above 128. Buglink: https://bugs.launchpad.net/bugs/1863247 Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20200214194643.23317-2-richard.henderson@linaro.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* z2: Make providing flash images non-mandatoryGuenter Roeck2020-02-211-6/+0Star
| | | | | | | | | | | | Up to now, the z2 machine only boots if a flash image is provided. This is not really necessary; the machine can boot from initrd or from SD without it. At the same time, having to provide dummy flash images is a nuisance and does not add any real value. Make it optional. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20200217210903.18602-1-linux@roeck-us.net Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* mainstone: Make providing flash images non-mandatoryGuenter Roeck2020-02-211-10/+1Star
| | | | | | | | | | | | Up to now, the mainstone machine only boots if two flash images are provided. This is not really necessary; the machine can boot from initrd or from SD without it. At the same time, having to provide dummy flash images is a nuisance and does not add any real value. Make it optional. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20200217210824.18513-1-linux@roeck-us.net Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* hw/misc/iotkit-secctl: Fix writing to 'PPC Interrupt Clear' registerPhilippe Mathieu-Daudé2020-02-211-1/+1
| | | | | | | | | | | | | | | | Fix warning reported by Clang static code analyzer: CC hw/misc/iotkit-secctl.o hw/misc/iotkit-secctl.c:343:9: warning: Value stored to 'value' is never read value &= 0x00f000f3; ^ ~~~~~~~~~~ Fixes: b3717c23e1c Reported-by: Clang Static Analyzer Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20200217132922.24607-1-f4bug@amsat.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* aspeed/scu: Implement chip ID registerJoel Stanley2020-02-211-0/+13
| | | | | | | | | | | This returns a fixed but non-zero value for the chip id. Signed-off-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Andrew Jeffery <andrew@aj.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20200121013302.43839-3-joel@jms.id.au Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* aspeed/scu: Create separate write callbacksJoel Stanley2020-02-211-23/+57
| | | | | | | | | | | | | This splits the common write callback into separate ast2400 and ast2500 implementations. This makes it clearer when implementing differing behaviour. Signed-off-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Andrew Jeffery <andrew@aj.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20200121013302.43839-2-joel@jms.id.au Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-5.0-20200221' ↵Peter Maydell2020-02-2129-166/+864
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | into staging ppc patch queue 2020-02-21 Here's the next patch of ppc target patches. Highlights are: * Some fixes for CAS / unplug interactions * Remove some leaks of device trees * Some fixes for the PHB3 and PHB4 devices * Support for NVDIMMs on the pseries machine type * Assorted other fixes and cleanups # gpg: Signature made Fri 21 Feb 2020 03:35:40 GMT # gpg: using RSA key 75F46586AE61A66CC44E87DC6C38CACA20D9B392 # gpg: Good signature from "David Gibson <david@gibson.dropbear.id.au>" [full] # gpg: aka "David Gibson (Red Hat) <dgibson@redhat.com>" [full] # gpg: aka "David Gibson (ozlabs.org) <dgibson@ozlabs.org>" [full] # gpg: aka "David Gibson (kernel.org) <dwg@kernel.org>" [unknown] # Primary key fingerprint: 75F4 6586 AE61 A66C C44E 87DC 6C38 CACA 20D9 B392 * remotes/dgibson/tags/ppc-for-5.0-20200221: hw/ppc/virtex_ml507:fix leak of fdevice tree blob spapr: Fix handling of unplugged devices during CAS and migration spapr: Don't use spapr_drc_needed() in CAS code ppc: free 'fdt' after reset the machine target/ppc/cpu.h: Clean up comments in the struct CPUPPCState definition target/ppc/cpu.h: Move fpu related members closer in cpu env target/ppc: Fix typo in comments spapr: Allow changing offset for -kernel image pnv/phb3: Add missing break statement pnv/phb4: Fix error path in pnv_pec_realize() pnv/phb3: Convert 1u to 1ull target/ppc/cpu.h: Remove duplicate includes spapr: Add Hcalls to support PAPR NVDIMM device spapr: Add NVDIMM device support nvdimm: add uuid property to nvdimm mem: move nvdimm_device_list to utilities ppc: function to setup latest class options ppc/pnv: Fix PCI_EXPRESS dependency qtest: Fix rtas dependencies spapr/rtas: Print message from "ibm,os-term" Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
| * hw/ppc/virtex_ml507:fix leak of fdevice tree blobChen Qun2020-02-201-0/+1
| | | | | | | | | | | | | | | | | | | | The device tree blob returned by load_device_tree is malloced. We should free it after cpu_physical_memory_write(). Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Chen Qun <kuhn.chenqun@huawei.com> Message-Id: <20200218091154.21696-3-kuhn.chenqun@huawei.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
| * spapr: Fix handling of unplugged devices during CAS and migrationGreg Kurz2020-02-201-2/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We already detect if a device is being hot plugged before CAS to trigger a CAS reboot and during migration to migrate the state of the associated DRC. But hot unplugging a device is also an asynchronous operation that requires the guest to take action. This means that if the guest is migrated after the hot unplug event was sent but before it could release the device with RTAS, the destination QEMU doesn't know about the pending unplug operation and doesn't actually remove the device when the guest finally releases it. Similarly, if the unplug request is fired before CAS, the guest isn't notified of the change, just like with hotplug. It ends up booting with the device still present in the DT and configures it, just like it was never removed. Even weirder, since the event is still queued, it will be eventually processed when some other unrelated event is posted to the guest. Enhance spapr_drc_transient() to also return true if an unplug request is pending. This fixes the issue at CAS with a CAS reboot request and causes the DRC state to be migrated. Some extra care is still needed to inform the destination that an unplug request is pending : migrate the unplug_requested field of the DRC in an optional subsection. This might break backwards migration, but this is still better than ending with an inconsistent guest. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <158169248798.3465937.1108351365840514270.stgit@bahia.lan> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
| * spapr: Don't use spapr_drc_needed() in CAS codeGreg Kurz2020-02-203-12/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We currently don't support hotplug of devices between boot and CAS. If this happens a CAS reboot is triggered. We detect this during CAS using the spapr_drc_needed() function which is essentially a VMStateDescription .needed callback. Even if the condition for CAS reboot happens to be the same as for DRC migration, it looks wrong to piggyback a migration helper for this. Introduce a helper with slightly more explicit name and use it in both CAS and DRC migration code. Since a subsequent patch will enhance this helper to cover the case of hot unplug, let's go for spapr_drc_transient(). While here convert spapr_hotplugged_dev_before_cas() to the "transient" wording as well. This doesn't change any behaviour. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <158169248180.3465937.9531405453362718771.stgit@bahia.lan> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
| * ppc: free 'fdt' after reset the machinePan Nengyuan2020-02-202-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 'fdt' forgot to clean both e500 and pnv when we call 'system_reset' on ppc, this patch fix it. The leak stacks are as follow: Direct leak of 4194304 byte(s) in 4 object(s) allocated from: #0 0x7fafe37dd970 in __interceptor_calloc (/lib64/libasan.so.5+0xef970) #1 0x7fafe2e3149d in g_malloc0 (/lib64/libglib-2.0.so.0+0x5249d) #2 0x561876f7f80d in create_device_tree /mnt/sdb/qemu-new/qemu/device_tree.c:40 #3 0x561876b7ac29 in ppce500_load_device_tree /mnt/sdb/qemu-new/qemu/hw/ppc/e500.c:364 #4 0x561876b7f437 in ppce500_reset_device_tree /mnt/sdb/qemu-new/qemu/hw/ppc/e500.c:617 #5 0x56187718b1ae in qemu_devices_reset /mnt/sdb/qemu-new/qemu/hw/core/reset.c:69 #6 0x561876f6938d in qemu_system_reset /mnt/sdb/qemu-new/qemu/vl.c:1412 #7 0x561876f6a25b in main_loop_should_exit /mnt/sdb/qemu-new/qemu/vl.c:1645 #8 0x561876f6a398 in main_loop /mnt/sdb/qemu-new/qemu/vl.c:1679 #9 0x561876f7da8e in main /mnt/sdb/qemu-new/qemu/vl.c:4438 #10 0x7fafde16b812 in __libc_start_main ../csu/libc-start.c:308 #11 0x5618765c055d in _start (/mnt/sdb/qemu-new/qemu/build/ppc64-softmmu/qemu-system-ppc64+0x2b1555d) Direct leak of 1048576 byte(s) in 1 object(s) allocated from: #0 0x7fc0a6f1b970 in __interceptor_calloc (/lib64/libasan.so.5+0xef970) #1 0x7fc0a656f49d in g_malloc0 (/lib64/libglib-2.0.so.0+0x5249d) #2 0x55eb05acd2ca in pnv_dt_create /mnt/sdb/qemu-new/qemu/hw/ppc/pnv.c:507 #3 0x55eb05ace5bf in pnv_reset /mnt/sdb/qemu-new/qemu/hw/ppc/pnv.c:578 #4 0x55eb05f2f395 in qemu_system_reset /mnt/sdb/qemu-new/qemu/vl.c:1410 #5 0x55eb05f43850 in main /mnt/sdb/qemu-new/qemu/vl.c:4403 #6 0x7fc0a18a9812 in __libc_start_main ../csu/libc-start.c:308 #7 0x55eb0558655d in _start (/mnt/sdb/qemu-new/qemu/build/ppc64-softmmu/qemu-system-ppc64+0x2b1555d) Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com> Message-Id: <20200214033206.4395-1-pannengyuan@huawei.com> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
| * target/ppc/cpu.h: Clean up comments in the struct CPUPPCState definitionBALATON Zoltan2020-02-201-91/+54Star
| | | | | | | | | | | | | | | | | | | | The cpu env struct is quite complex but comments supposed to explain it in its definition just make it harder to read. Reformat and reword some comments to make it clearer and more readable. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <8707144ab1ccf9c5c89a39c2d7a0b02307ca25d4.1581888834.git.balaton@eik.bme.hu> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
| * target/ppc/cpu.h: Move fpu related members closer in cpu envBALATON Zoltan2020-02-201-5/+4Star
| | | | | | | | | | | | | | | | | | Move fp_status and fpscr closer to other floating point and vector related members in cpu env definition so they are in one group. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <5b50e9e7eec2c383ae878b397d0b2927efc9ea43.1581888834.git.balaton@eik.bme.hu> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
| * target/ppc: Fix typo in commentsBALATON Zoltan2020-02-202-5/+5
| | | | | | | | | | | | | | | | | | "Deferred" was misspelled as "differed" in some comments, correct this typo, Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <20200214155748.0896B745953@zero.eik.bme.hu> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
| * spapr: Allow changing offset for -kernel imageAlexey Kardashevskiy2020-02-202-7/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | This allows moving the kernel in the guest memory. The option is useful for step debugging (as Linux is linked at 0x0); it also allows loading grub which is normally linked to run at 0x20000. This uses the existing kernel address by default. Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Message-Id: <20200203032943.121178-6-aik@ozlabs.ru> Reviewed-by: Fabiano Rosas <farosas@linux.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
| * pnv/phb3: Add missing break statementGreg Kurz2020-02-201-0/+1
| | | | | | | | | | | | | | | | | | | | | | We obviously don't want to print out an error message if addr points to a valid register. Reported-by: Coverity CID 1419391 Missing break in switch Fixes: 9ae1329ee2fe "ppc/pnv: Add models for POWER8 PHB3 PCIe Host bridge" Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <158153365202.3229002.11521084761048102466.stgit@bahia.lan> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
| * pnv/phb4: Fix error path in pnv_pec_realize()Greg Kurz2020-02-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | Obviously, we want to pass &local_err so that we can check it then line below, not errp. Reported-by: Coverity CID 1419395 'Constant' variable guards dead code Fixes: 4f9924c4d4cf "ppc/pnv: Add models for POWER9 PHB4 PCIe Host bridge" Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <158153364605.3229002.2796177658957390343.stgit@bahia.lan> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
| * pnv/phb3: Convert 1u to 1ullGreg Kurz2020-02-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | As reported by Coverity defect CID 1419397, the 'j' variable goes up to 63 and shouldn't be used to left shift a 32-bit integer. The result of the operation goes to a 64-bit integer : use a 64-bit constant. Reported-by: Coverity CID 1419397 Bad bit shift operation Fixes: 9ae1329ee2fe "ppc/pnv: Add models for POWER8 PHB3 PCIe Host bridge" Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <158153364010.3229002.8004283672455615950.stgit@bahia.lan> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
| * target/ppc/cpu.h: Remove duplicate includesBALATON Zoltan2020-02-201-2/+0Star
| | | | | | | | | | | | | | | | | | | | | | Commit 74433bf083b added some includes but added them twice. Since these are guarded against multiple inclusion including them once is enough. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <20200212223207.5A37574637F@zero.eik.bme.hu> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
| * spapr: Add Hcalls to support PAPR NVDIMM deviceShivaprasad G Bhat2020-02-202-1/+305
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements few of the necessary hcalls for the nvdimm support. PAPR semantics is such that each NVDIMM device is comprising of multiple SCM(Storage Class Memory) blocks. The guest requests the hypervisor to bind each of the SCM blocks of the NVDIMM device using hcalls. There can be SCM block unbind requests in case of driver errors or unplug(not supported now) use cases. The NVDIMM label read/writes are done through hcalls. Since each virtual NVDIMM device is divided into multiple SCM blocks, the bind, unbind, and queries using hcalls on those blocks can come independently. This doesn't fit well into the qemu device semantics, where the map/unmap are done at the (whole)device/object level granularity. The patch doesnt actually bind/unbind on hcalls but let it happen at the device_add/del phase itself instead. The guest kernel makes bind/unbind requests for the virtual NVDIMM device at the region level granularity. Without interleaving, each virtual NVDIMM device is presented as a separate guest physical address range. So, there is no way a partial bind/unbind request can come for the vNVDIMM in a hcall for a subset of SCM blocks of a virtual NVDIMM. Hence it is safe to do bind/unbind everything during the device_add/del. Signed-off-by: Shivaprasad G Bhat <sbhat@linux.ibm.com> Message-Id: <158131059899.2897.11515211602702956854.stgit@lep8c.aus.stglabs.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
| * spapr: Add NVDIMM device supportShivaprasad G Bhat2020-02-209-11/+309
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for NVDIMM devices for sPAPR. Piggyback on existing nvdimm device interface in QEMU to support virtual NVDIMM devices for Power. Create the required DT entries for the device (some entries have dummy values right now). The patch creates the required DT node and sends a hotplug interrupt to the guest. Guest is expected to undertake the normal DR resource add path in response and start issuing PAPR SCM hcalls. The device support is verified based on the machine version unlike x86. This is how it can be used .. Ex : For coldplug, the device to be added in qemu command line as shown below -object memory-backend-file,id=memnvdimm0,prealloc=yes,mem-path=/tmp/nvdimm0,share=yes,size=1073872896 -device nvdimm,label-size=128k,uuid=75a3cdd7-6a2f-4791-8d15-fe0a920e8e9e,memdev=memnvdimm0,id=nvdimm0,slot=0 For hotplug, the device to be added from monitor as below object_add memory-backend-file,id=memnvdimm0,prealloc=yes,mem-path=/tmp/nvdimm0,share=yes,size=1073872896 device_add nvdimm,label-size=128k,uuid=75a3cdd7-6a2f-4791-8d15-fe0a920e8e9e,memdev=memnvdimm0,id=nvdimm0,slot=0 Signed-off-by: Shivaprasad G Bhat <sbhat@linux.ibm.com> Signed-off-by: Bharata B Rao <bharata@linux.ibm.com> [Early implementation] Message-Id: <158131058078.2897.12767731856697459923.stgit@lep8c.aus.stglabs.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
| * nvdimm: add uuid property to nvdimmShivaprasad G Bhat2020-02-202-0/+47
| | | | | | | | | | | | | | | | | | | | | | For ppc64, PAPR requires the nvdimm device to have UUID property set in the device tree. Add an option to get it from the user. Signed-off-by: Shivaprasad G Bhat <sbhat@linux.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <158131056931.2897.14057087440721445976.stgit@lep8c.aus.stglabs.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
| * mem: move nvdimm_device_list to utilitiesShivaprasad G Bhat2020-02-204-27/+38
| | | | | | | | | | | | | | | | | | | | | | nvdimm_device_list is required for parsing the list for devices in subsequent patches. Move it to common utility area. Signed-off-by: Shivaprasad G Bhat <sbhat@linux.ibm.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <158131055857.2897.15658377276504711773.stgit@lep8c.aus.stglabs.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
| * ppc: function to setup latest class optionsMichael S. Tsirkin2020-02-201-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | We are going to add more init for the latest machine, so move the setup to a function so we don't have to change the DEFINE_SPAPR_MACHINE macro each time. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <20200207064628.1196095-1-mst@redhat.com> Reviewed-by: Laurent Vivier <lvivier@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
| * ppc/pnv: Fix PCI_EXPRESS dependencyLaurent Vivier2020-02-201-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When PHB4 bridge has been added, the dependencies to PCIE_PORT has been added to XIVE_SPAPR and indirectly to PSERIES. The build of the PowerNV machine is fine while we also build the PSERIES machine. If we disable the PSERIES machine, the PowerNV build fails because the PCI Express files are not built: /usr/bin/ld: hw/ppc/pnv.o: in function `pnv_chip_power8_pic_print_info': .../hw/ppc/pnv.c:623: undefined reference to `pnv_phb3_msi_pic_print_info' /usr/bin/ld: hw/ppc/pnv.o: in function `pnv_chip_power9_pic_print_info': .../hw/ppc/pnv.c:639: undefined reference to `pnv_phb4_pic_print_info' /usr/bin/ld: ../hw/usb/hcd-ehci-pci.o: in function `usb_ehci_pci_write_config': .../hw/usb/hcd-ehci-pci.c:129: undefined reference to `pci_default_write_config' /usr/bin/ld: ../hw/usb/hcd-ehci-pci.o: in function `usb_ehci_pci_realize': .../hw/usb/hcd-ehci-pci.c:68: undefined reference to `pci_allocate_irq' /usr/bin/ld: .../hw/usb/hcd-ehci-pci.c:72: undefined reference to `pci_register_bar' /usr/bin/ld: ../hw/usb/hcd-ehci-pci.o:(.data.rel+0x50): undefined reference to `vmstate_pci_device' This patch fixes the problem by adding needed dependencies to POWERNV. Fixes: 4f9924c4d4cf ("ppc/pnv: Add models for POWER9 PHB4 PCIe Host bridge") Signed-off-by: Laurent Vivier <lvivier@redhat.com> Message-Id: <20200205232016.588202-3-lvivier@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
| * qtest: Fix rtas dependenciesLaurent Vivier2020-02-201-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | qtest "rtas" command is only available with pseries not all ppc64 targets, so if I try to compile only powernv machine, the build fails with: /usr/bin/ld: qtest.o: in function `qtest_process_command': .../qtest.c:645: undefined reference to `qtest_rtas_call' We fix this by enabling rtas command only with pseries machine. Fixes: eeddd59f5962 ("tests: add RTAS command in the protocol") Signed-off-by: Laurent Vivier <lvivier@redhat.com> Message-Id: <20200205232016.588202-2-lvivier@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
| * spapr/rtas: Print message from "ibm,os-term"Alexey Kardashevskiy2020-02-201-0/+7
| | | | | | | | | | | | | | | | | | | | | | The "ibm,os-term" RTAS call has a single parameter which is a pointer to a message from the guest kernel about the termination cause; this prints it. Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Message-Id: <20200203032044.118585-1-aik@ozlabs.ru> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* | Merge remote-tracking branch 'remotes/maxreitz/tags/pull-block-2020-02-20' ↵Peter Maydell2020-02-2128-180/+659
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | into staging Block patches: - qemu-img convert: New --target-is-zero parameter - qcow2: Specify non-default compression type flag - optionally flat output for query-named-block-nodes - some fixes - pseudo-creation of images on block devices is now done by a generic block layer function # gpg: Signature made Thu 20 Feb 2020 16:05:34 GMT # gpg: using RSA key 91BEB60A30DB3E8857D11829F407DB0061D5CF40 # gpg: issuer "mreitz@redhat.com" # gpg: Good signature from "Max Reitz <mreitz@redhat.com>" [full] # Primary key fingerprint: 91BE B60A 30DB 3E88 57D1 1829 F407 DB00 61D5 CF40 * remotes/maxreitz/tags/pull-block-2020-02-20: iotests: Test snapshot -l field separation block: Fix VM size field width in snapshot dump iotests: Test convert -n -B to backing-less target qemu-img: Fix convert -n -B for backing-less targets iotests: Add test for image creation fallback iscsi: Drop iscsi_co_create_opts() file-posix: Drop hdev_co_create_opts() block: Generic file creation fallback block/nbd: Fix hang in .bdrv_close() iotests/279: Fix for non-qcow2 formats block/backup-top: fix flags handling block: always fill entire LUKS header space with zeros qemu-img: Add --target-is-zero to convert qapi: Allow getting flat output from 'query-named-block-nodes' iotests/147: Fix drive parameters iotests: Remove the superfluous 2nd check for the availability of quorum docs: qcow2: introduce compression type feature docs: improve qcow2 spec about extending image header Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
| * | iotests: Test snapshot -l field separationMax Reitz2020-02-203-0/+85
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a test that all fields in "qemu-img snapshot -l"s output are separated by spaces. Signed-off-by: Max Reitz <mreitz@redhat.com> Message-Id: <20200117105859.241818-3-mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> [mreitz: Renamed test from 284 to 286] Signed-off-by: Max Reitz <mreitz@redhat.com>
| * | block: Fix VM size field width in snapshot dumpMax Reitz2020-02-201-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When printing the snapshot list (e.g. with qemu-img snapshot -l), the VM size field is only seven characters wide. As of de38b5005e9, this is not necessarily sufficient: We generally print three digits, and this may require a decimal point. Also, the unit field grew from something as plain as "M" to " MiB". This means that number and unit may take up eight characters in total; but we also want spaces in front. Considering previously the maximum width was four characters and the field width was chosen to be three characters wider, let us adjust the field width to be eleven now. Fixes: de38b5005e946aa3714963ea4c501e279e7d3666 Buglink: https://bugs.launchpad.net/qemu/+bug/1859989 Signed-off-by: Max Reitz <mreitz@redhat.com> Message-Id: <20200117105859.241818-2-mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
| * | iotests: Test convert -n -B to backing-less targetMax Reitz2020-02-202-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | This must not crash. Signed-off-by: Max Reitz <mreitz@redhat.com> Message-Id: <20200121155915.98232-3-mreitz@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
| * | qemu-img: Fix convert -n -B for backing-less targetsMax Reitz2020-02-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | s.target_has_backing does not reflect whether the target BDS has a backing file; it only tells whether we should use a backing file during conversion (specified by -B). As such, if you use convert -n, the target does not necessarily actually have a backing file, and then dereferencing out_bs->backing fails here. When converting to an existing file, we should set target_backing_sectors to a negative value, because first, as the comment explains, this value is only used for optimization, so it is always fine to do that. Second, we use this value to determine where the target must be initialized to zeroes (overlays are initialized to zero after the end of their backing file). When converting to an existing file, we cannot assume that to be true. Cc: qemu-stable@nongnu.org Fixes: 351c8efff9ad809c822d55620df54d575d536f68 ("qemu-img: Special post-backing convert handling") Signed-off-by: Max Reitz <mreitz@redhat.com> Message-Id: <20200121155915.98232-2-mreitz@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2024-12-22 13:25:15 +0100