aboutsummaryrefslogtreecommitdiff
path: root/target
AgeCommit message (Collapse)Author
2020-03-19target/rx: TCG helpersYoshinori Sato
Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Yoshinori Sato <ysato@users.sourceforge.jp> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> [PMD: Removed tlb_fill, extracted from patch of Yoshinori Sato 'Convert to CPUClass::tlb_fill'] Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200224141923.82118-6-ysato@users.sourceforge.jp> Acked-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2020-03-19target/rx: TCG translationYoshinori Sato
This part only supported RXv1 instructions. Instruction manual: https://www.renesas.com/us/en/doc/products/mpumcu/doc/rx_family/r01us0032ej0120_rxsm.pdf Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Yoshinori Sato <ysato@users.sourceforge.jp> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20200224141923.82118-5-ysato@users.sourceforge.jp> Acked-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2020-03-19Merge remote-tracking branch ↵Peter Maydell
'remotes/ehabkost/tags/x86-and-machine-pull-request' into staging x86 and machine queue for 5.0 soft freeze Bug fixes: * memory encryption: Disable mem merge (Dr. David Alan Gilbert) Features: * New EPYC CPU definitions (Babu Moger) * Denventon-v2 CPU model (Tao Xu) * New 'note' field on versioned CPU models (Tao Xu) Cleanups: * x86 CPU topology cleanups (Babu Moger) * cpu: Use DeviceClass reset instead of a special CPUClass reset (Peter Maydell) # gpg: Signature made Wed 18 Mar 2020 01:16:43 GMT # gpg: using RSA key 5A322FD5ABC4D3DBACCFD1AA2807936F984DC5A6 # gpg: issuer "ehabkost@redhat.com" # gpg: Good signature from "Eduardo Habkost <ehabkost@redhat.com>" [full] # Primary key fingerprint: 5A32 2FD5 ABC4 D3DB ACCF D1AA 2807 936F 984D C5A6 * remotes/ehabkost/tags/x86-and-machine-pull-request: hw/i386: Rename apicid_from_topo_ids to x86_apicid_from_topo_ids hw/i386: Update structures to save the number of nodes per package hw/i386: Remove unnecessary initialization in x86_cpu_new machine: Add SMP Sockets in CpuTopology hw/i386: Consolidate topology functions hw/i386: Introduce X86CPUTopoInfo to contain topology info cpu: Use DeviceClass reset instead of a special CPUClass reset machine/memory encryption: Disable mem merge hw/i386: Rename X86CPUTopoInfo structure to X86CPUTopoIDs i386: Add 2nd Generation AMD EPYC processors i386: Add missing cpu feature bits in EPYC model target/i386: Add new property note to versioned CPU models target/i386: Add Denverton-v2 (no MPX) CPU model Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-03-18Merge remote-tracking branch ↵Peter Maydell
'remotes/stsquad/tags/pull-testing-and-gdbstub-170320-1' into staging Testing and gdbstub updates: - docker updates for VirGL - re-factor gdbstub for static GDBState - re-factor gdbstub for dynamic arrays - add SVE support to arm gdbstub - add some guest debug tests to check-tcg - add aarch64 userspace register tests - remove packet size limit to gdbstub - simplify gdbstub monitor code - report vContSupported in gdbstub to use proper single-step # gpg: Signature made Tue 17 Mar 2020 17:47:46 GMT # gpg: using RSA key 6685AE99E75167BCAFC8DF35FBD0DB095A9E2A44 # gpg: Good signature from "Alex Bennée (Master Work Key) <alex.bennee@linaro.org>" [full] # Primary key fingerprint: 6685 AE99 E751 67BC AFC8 DF35 FBD0 DB09 5A9E 2A44 * remotes/stsquad/tags/pull-testing-and-gdbstub-170320-1: (28 commits) gdbstub: Fix single-step issue by confirming 'vContSupported+' feature to gdb gdbstub: do not split gdb_monitor_write payload gdbstub: change GDBState.last_packet to GByteArray tests/tcg/aarch64: add test-sve-ioctl guest-debug test tests/tcg/aarch64: add SVE iotcl test tests/tcg/aarch64: add a gdbstub testcase for SVE registers tests/guest-debug: add a simple test runner configure: allow user to specify what gdb to use tests/tcg/aarch64: userspace system register test target/arm: don't bother with id_aa64pfr0_read for USER_ONLY target/arm: generate xml description of our SVE registers target/arm: default SVE length to 64 bytes for linux-user target/arm: explicitly encode regnum in our XML target/arm: prepare for multiple dynamic XMLs gdbstub: extend GByteArray to read register helpers target/i386: use gdb_get_reg helpers target/m68k: use gdb_get_reg helpers target/arm: use gdb_get_reg helpers gdbstub: add helper for 128 bit registers gdbstub: move mem_buf to GDBState and use GByteArray ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-03-18Merge remote-tracking branch 'remotes/armbru/tags/pull-error-2020-03-17' ↵Peter Maydell
into staging Error reporting patches for 2020-03-17 # gpg: Signature made Tue 17 Mar 2020 16:30:49 GMT # gpg: using RSA key 354BC8B3D7EB2A6B68674E5F3870B400EB918653 # gpg: issuer "armbru@redhat.com" # gpg: Good signature from "Markus Armbruster <armbru@redhat.com>" [full] # gpg: aka "Markus Armbruster <armbru@pond.sub.org>" [full] # Primary key fingerprint: 354B C8B3 D7EB 2A6B 6867 4E5F 3870 B400 EB91 8653 * remotes/armbru/tags/pull-error-2020-03-17: hw/sd/ssi-sd: fix error handling in ssi_sd_realize xen-block: Use one Error * variable instead of two hw/misc/ivshmem: Use one Error * variable instead of two Use &error_abort instead of separate assert() Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-03-18Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-5.0-20200317' ↵Peter Maydell
into staging ppc patch queue 2020-03-17 Here's my final pull request for the qemu-5.0 soft freeze. Sorry this is just under the wire - I hit some last minute problems that took a while to fix up and retest. Highlights are: * Numerous fixes for the FWNMI feature * A handful of cleanups to the device tree construction code * Numerous fixes for the spapr-vscsi device * A number of fixes and cleanups for real mode (MMU off) softmmu handling * Fixes for handling of the PAPR RMA * Better handling of hotplug/unplug events during boot * Assorted other fixes # gpg: Signature made Tue 17 Mar 2020 09:55:07 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-20200317: (45 commits) pseries: Update SLOF firmware image ppc/spapr: Ignore common "ibm,nmi-interlock" Linux bug ppc/spapr: Implement FWNMI System Reset delivery target/ppc: allow ppc_cpu_do_system_reset to take an alternate vector ppc/spapr: Allow FWNMI on TCG ppc/spapr: Fix FWNMI machine check interrupt delivery ppc/spapr: Add FWNMI System Reset state ppc/spapr: Change FWNMI names ppc/spapr: Fix FWNMI machine check failure handling spapr: Rename DT functions to newer naming convention spapr: Move creation of ibm,architecture-vec-5 property spapr: Move creation of ibm,dynamic-reconfiguration-memory dt node spapr/rtas: Reserve space for RTAS blob and log pseries: Update SLOF firmware image ppc/spapr: Move GPRs setup to one place target/ppc: Fix rlwinm on ppc64 spapr/xive: use SPAPR_IRQ_IPI to define IPI ranges exposed to the guest hw/scsi/spapr_vscsi: Convert debug fprintf() to trace event hw/scsi/spapr_vscsi: Prevent buffer overflow hw/scsi/spapr_vscsi: Do not mix SRP IU size with DMA buffer size ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-03-17hw/i386: Update structures to save the number of nodes per packageBabu Moger
Update structures X86CPUTopoIDs and CPUX86State to hold the number of nodes per package. This is required to build EPYC mode topology. Signed-off-by: Babu Moger <babu.moger@amd.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <158396720035.58170.1973738805301006456.stgit@naples-babu.amd.com>
2020-03-17hw/i386: Consolidate topology functionsBabu Moger
Now that we have all the parameters in X86CPUTopoInfo, we can just pass the structure to calculate the offsets and width. Signed-off-by: Babu Moger <babu.moger@amd.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <158396717953.58170.5628042059144117669.stgit@naples-babu.amd.com>
2020-03-17cpu: Use DeviceClass reset instead of a special CPUClass resetPeter Maydell
The CPUClass has a 'reset' method. This is a legacy from when TYPE_CPU used not to inherit from TYPE_DEVICE. We don't need it any more, as we can simply use the TYPE_DEVICE reset. The 'cpu_reset()' function is kept as the API which most places use to reset a CPU; it is now a wrapper which calls device_cold_reset() and then the tracepoint function. This change should not cause CPU objects to be reset more often than they are at the moment, because: * nobody is directly calling device_cold_reset() or qdev_reset_all() on CPU objects * no CPU object is on a qbus, so they will not be reset either by somebody calling qbus_reset_all()/bus_cold_reset(), or by the main "reset sysbus and everything in the qbus tree" reset that most devices are reset by Note that this does not change the need for each machine or whatever to use qemu_register_reset() to arrange to call cpu_reset() -- that is necessary because CPU objects are not on any qbus, so they don't get reset when the qbus tree rooted at the sysbus bus is reset, and this isn't being changed here. All the changes to the files under target/ were made using the included Coccinelle script, except: (1) the deletion of the now-inaccurate and not terribly useful "CPUClass::reset" comments was done with a perl one-liner afterwards: perl -n -i -e '/ CPUClass::reset/ or print' target/*/*.c (2) this bit of the s390 change was done by hand, because the Coccinelle script is not sophisticated enough to handle the parent_reset call being inside another function: | @@ -96,8 +96,9 @@ static void s390_cpu_reset(CPUState *s, cpu_reset_type type) | S390CPU *cpu = S390_CPU(s); | S390CPUClass *scc = S390_CPU_GET_CLASS(cpu); | CPUS390XState *env = &cpu->env; |+ DeviceState *dev = DEVICE(s); | |- scc->parent_reset(s); |+ scc->parent_reset(dev); | cpu->env.sigp_order = 0; | s390_cpu_set_state(S390_CPU_STATE_STOPPED, cpu); Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20200303100511.5498-1-peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2020-03-17i386: Add 2nd Generation AMD EPYC processorsMoger, Babu
Adds the support for 2nd Gen AMD EPYC Processors. The model display name will be EPYC-Rome. Adds the following new feature bits on top of the feature bits from the first generation EPYC models. perfctr-core : core performance counter extensions support. Enables the VM to use extended performance counter support. It enables six programmable counters instead of four counters. clzero : instruction zeroes out the 64 byte cache line specified in RAX. xsaveerptr : XSAVE, XSAVE, FXSAVEOPT, XSAVEC, XSAVES always save error pointers and FXRSTOR, XRSTOR, XRSTORS always restore error pointers. wbnoinvd : Write back and do not invalidate cache ibpb : Indirect Branch Prediction Barrier amd-stibp : Single Thread Indirect Branch Predictor clwb : Cache Line Write Back and Retain xsaves : XSAVES, XRSTORS and IA32_XSS support rdpid : Read Processor ID instruction support umip : User-Mode Instruction Prevention support The Reference documents are available at https://developer.amd.com/wp-content/resources/55803_0.54-PUB.pdf https://www.amd.com/system/files/TechDocs/24594.pdf Depends on following kernel commits: 40bc47b08b6e ("kvm: x86: Enumerate support for CLZERO instruction") 504ce1954fba ("KVM: x86: Expose XSAVEERPTR to the guest") 6d61e3c32248 ("kvm: x86: Expose RDPID in KVM_GET_SUPPORTED_CPUID") 52297436199d ("kvm: svm: Update svm_xsaves_supported") Signed-off-by: Babu Moger <babu.moger@amd.com> Message-Id: <157314966312.23828.17684821666338093910.stgit@naples-babu.amd.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2020-03-17i386: Add missing cpu feature bits in EPYC modelMoger, Babu
Adds the following missing CPUID bits: perfctr-core : core performance counter extensions support. Enables the VM to use extended performance counter support. It enables six programmable counters instead of 4 counters. clzero : instruction zeroes out the 64 byte cache line specified in RAX. xsaveerptr : XSAVE, XSAVE, FXSAVEOPT, XSAVEC, XSAVES always save error pointers and FXRSTOR, XRSTOR, XRSTORS always restore error pointers. ibpb : Indirect Branch Prediction Barrie. xsaves : XSAVES, XRSTORS and IA32_XSS supported. Depends on following kernel commits: 40bc47b08b6e ("kvm: x86: Enumerate support for CLZERO instruction") 504ce1954fba ("KVM: x86: Expose XSAVEERPTR to the guest") 52297436199d ("kvm: svm: Update svm_xsaves_supported") These new features will be added in EPYC-v3. The -cpu help output after the change. x86 EPYC-v1 AMD EPYC Processor x86 EPYC-v2 AMD EPYC Processor (with IBPB) x86 EPYC-v3 AMD EPYC Processor Signed-off-by: Babu Moger <babu.moger@amd.com> Message-Id: <157314965662.23828.3063243729449408327.stgit@naples-babu.amd.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2020-03-17target/i386: Add new property note to versioned CPU modelsTao Xu
Add additional information for -cpu help to indicate the changes in this version of CPU model. Suggested-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Tao Xu <tao3.xu@intel.com> Message-Id: <20200212081328.7385-4-tao3.xu@intel.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2020-03-17target/i386: Add Denverton-v2 (no MPX) CPU modelTao Xu
Because MPX is being removed from the linux kernel, remove MPX feature from Denverton. Signed-off-by: Tao Xu <tao3.xu@intel.com> Message-Id: <20200212081328.7385-2-tao3.xu@intel.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2020-03-17Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into stagingPeter Maydell
* Bugfixes all over the place * get/set_uint cleanups (Felipe) * Lock guard support (Stefan) * MemoryRegion ownership cleanup (Philippe) * AVX512 optimization for buffer_is_zero (Robert) # gpg: Signature made Tue 17 Mar 2020 15:01:54 GMT # gpg: using RSA key BFFBD25F78C7AE83 # gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" [full] # gpg: aka "Paolo Bonzini <pbonzini@redhat.com>" [full] # Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4 E2F7 7E15 100C CD36 69B1 # Subkey fingerprint: F133 3857 4B66 2389 866C 7682 BFFB D25F 78C7 AE83 * remotes/bonzini/tags/for-upstream: (62 commits) hw/arm: Let devices own the MemoryRegion they create hw/arm: Remove unnecessary memory_region_set_readonly() on ROM alias hw/ppc/ppc405: Use memory_region_init_rom() with read-only regions hw/arm/stm32: Use memory_region_init_rom() with read-only regions hw/char: Let devices own the MemoryRegion they create hw/riscv: Let devices own the MemoryRegion they create hw/dma: Let devices own the MemoryRegion they create hw/display: Let devices own the MemoryRegion they create hw/core: Let devices own the MemoryRegion they create scripts/cocci: Patch to let devices own their MemoryRegions scripts/cocci: Patch to remove unnecessary memory_region_set_readonly() scripts/cocci: Patch to detect potential use of memory_region_init_rom hw/sparc: Use memory_region_init_rom() with read-only regions hw/sh4: Use memory_region_init_rom() with read-only regions hw/riscv: Use memory_region_init_rom() with read-only regions hw/ppc: Use memory_region_init_rom() with read-only regions hw/pci-host: Use memory_region_init_rom() with read-only regions hw/net: Use memory_region_init_rom() with read-only regions hw/m68k: Use memory_region_init_rom() with read-only regions hw/display: Use memory_region_init_rom() with read-only regions ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-03-17target/arm: don't bother with id_aa64pfr0_read for USER_ONLYAlex Bennée
For system emulation we need to check the state of the GIC before we report the value. However this isn't relevant to exporting of the value to linux-user and indeed breaks the exported value as set by modify_arm_cp_regs. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200316172155.971-20-alex.bennee@linaro.org>
2020-03-17target/arm: generate xml description of our SVE registersAlex Bennée
We also expose a the helpers to read/write the the registers. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Acked-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20200316172155.971-19-alex.bennee@linaro.org>
2020-03-17target/arm: default SVE length to 64 bytes for linux-userAlex Bennée
The Linux kernel chooses the default of 64 bytes for SVE registers on the basis that it is the largest size on known hardware that won't grow the signal frame. We still honour the sve-max-vq property and userspace can expand the number of lanes by calling PR_SVE_SET_VL. This should not make any difference to SVE enabled software as the SVE is of course vector length agnostic. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20200316172155.971-18-alex.bennee@linaro.org>
2020-03-17target/arm: explicitly encode regnum in our XMLAlex Bennée
This is described as optional but I'm not convinced of the numbering when multiple target fragments are sent. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20200316172155.971-17-alex.bennee@linaro.org>
2020-03-17target/arm: prepare for multiple dynamic XMLsAlex Bennée
We will want to generate similar dynamic XML for gdbstub support of SVE registers (the upstream doesn't use XML). To that end lightly rename a few things to make the distinction. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Acked-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20200316172155.971-16-alex.bennee@linaro.org>
2020-03-17gdbstub: extend GByteArray to read register helpersAlex Bennée
Instead of passing a pointer to memory now just extend the GByteArray to all the read register helpers. They can then safely append their data through the normal way. We don't bother with this abstraction for write registers as we have already ensured the buffer being copied from is the correct size. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Acked-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Damien Hedde <damien.hedde@greensocs.com> Message-Id: <20200316172155.971-15-alex.bennee@linaro.org>
2020-03-17target/i386: use gdb_get_reg helpersAlex Bennée
This is cleaner than poking memory directly and will make later clean-ups easier. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200316172155.971-14-alex.bennee@linaro.org>
2020-03-17target/m68k: use gdb_get_reg helpersAlex Bennée
This is cleaner than poking memory directly and will make later clean-ups easier. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200316172155.971-13-alex.bennee@linaro.org>
2020-03-17target/arm: use gdb_get_reg helpersAlex Bennée
This is cleaner than poking memory directly and will make later clean-ups easier. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20200316172155.971-12-alex.bennee@linaro.org>
2020-03-17Use &error_abort instead of separate assert()Markus Armbruster
Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20200313170517.22480-2-armbru@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Acked-by: Alexander Bulekov <alxndr@bu.edu> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> [Unused Error *variable deleted]
2020-03-17target/ppc: allow ppc_cpu_do_system_reset to take an alternate vectorNicholas Piggin
Provide for an alternate delivery location, -1 defaults to the architected address. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Message-Id: <20200316142613.121089-7-npiggin@gmail.com> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-03-17ppc/spapr: Fix FWNMI machine check interrupt deliveryNicholas Piggin
FWNMI machine check delivery misses a few things that will make it fail with TCG at least (which we would like to allow in future to improve testing). It's not nice to scatter interrupt delivery logic around the tree, so move it to excp_helper.c and share code where possible. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Message-Id: <20200316142613.121089-5-npiggin@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-03-17target/ppc: Fix rlwinm on ppc64Vitaly Chikunov
rlwinm cannot just AND with Mask if shift value is zero on ppc64 when Mask Begin is greater than Mask End and high bits are set to 1. Note that PowerISA 3.0B says that for `rlwinm' ROTL32 is used, and ROTL32 is defined (in 3.3.14) so that rotated value should have two copies of lower word of the source value. This seems to be another incarnation of the fix from 820724d170 ("target-ppc: Fix rlwimi, rlwinm, rlwnm again"), except I leave optimization when Mask value is less than 32 bits. Fixes: 7b4d326f47 ("target-ppc: Use the new deposit and extract ops") Cc: qemu-stable@nongnu.org Signed-off-by: Vitaly Chikunov <vt@altlinux.org> Message-Id: <20200309204557.14836-1-vt@altlinux.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-03-16target/riscv: Fix VS mode interrupts forwarding.Rajnesh Kanwal
Currently riscv_cpu_local_irq_pending is used to find out pending interrupt and VS mode interrupts are being shifted to represent S mode interrupts in this function. So when the cause returned by this function is passed to riscv_cpu_do_interrupt to actually forward the interrupt, the VS mode forwarding check does not work as intended and interrupt is actually forwarded to hypervisor. This patch fixes this issue. Signed-off-by: Rajnesh Kanwal <rajnesh.kanwal49@gmail.com> Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2020-03-16target/riscv: Correctly implement TSR trapAlistair Francis
As reported in: https://bugs.launchpad.net/qemu/+bug/1851939 we weren't correctly handling illegal instructions based on the value of MSTATUS_TSR and the current privledge level. This patch fixes the issue raised in the bug by raising an illegal instruction if TSR is set and we are in S-Mode. Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Jonathan Behrens <jonathan@fintelia.io Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2020-03-17spapr,ppc: Simplify signature of kvmppc_rma_size()David Gibson
This function calculates the maximum size of the RMA as implied by the host's page size of structure of the VRMA (there are a number of other constraints on the RMA size which will supersede this one in many circumstances). The current interface takes the current RMA size estimate, and clamps it to the VRMA derived size. The only current caller passes in an arguably wrong value (it will match the current RMA estimate in some but not all cases). We want to fix that, but for now just keep concerns separated by having the KVM helper function just return the VRMA derived limit, and let the caller combine it with other constraints. We call the new function kvmppc_vrma_limit() to more clearly indicate its limited responsibility. The helper should only ever be called in the KVM enabled case, so replace its !CONFIG_KVM stub with an assert() rather than a dummy value. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cedric Le Goater <clg@fr.ibm.com> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2020-03-17target/ppc: Don't store VRMA SLBE persistentlyDavid Gibson
Currently, we construct the SLBE used for VRMA translations when the LPCR is written (which controls some bits in the SLBE), then use it later for translations. This is a bit complex and confusing - simplify it by simply constructing the SLBE directly from the LPCR when we need it. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2020-03-17target/ppc: Only calculate RMLS derived RMA limit on demandDavid Gibson
When the LPCR is written, we update the env->rmls field with the RMA limit it implies. Simplify things by just calculating the value directly from the LPCR value when we need it. It's possible this is a little slower, but it's unlikely to be significant, since this is only for real mode accesses in a translation configuration that's not used very often, and the whole thing is behind the qemu TLB anyway. Therefore, keeping the number of state variables down and not having to worry about making sure it's always in sync seems the better option. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2020-03-17target/ppc: Correct RMLS tableDavid Gibson
The table of RMA limits based on the LPCR[RMLS] field is slightly wrong. We're missing the RMLS == 0 => 256 GiB RMA option, which is available on POWER8, so add that. The comment that goes with the table is much more wrong. We *don't* filter invalid RMLS values when writing the LPCR, and there's not really a sensible way to do so. Furthermore, while in theory the set of RMLS values is implementation dependent, it seems in practice the same set has been available since around POWER4+ up until POWER8, the last model which supports RMLS at all. So, correct that as well. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org>
2020-03-17target/ppc: Streamline calculation of RMA limit from LPCR[RMLS]David Gibson
Currently we use a big switch statement in ppc_hash64_update_rmls() to work out what the right RMA limit is based on the LPCR[RMLS] field. There's no formula for this - it's just an arbitrary mapping defined by the existing CPU implementations - but we can make it a bit more readable by using a lookup table rather than a switch. In addition we can use the MiB/GiB symbols to make it a bit clearer. While there we add a bit of clarity and rationale to the comment about what happens if the LPCR[RMLS] doesn't contain a valid value. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2020-03-17target/ppc: Use class fields to simplify LPCR maskingDavid Gibson
When we store the Logical Partitioning Control Register (LPCR) we have a big switch statement to work out which are valid bits for the cpu model we're emulating. As well as being ugly, this isn't really conceptually correct, since it is based on the mmu_model variable, whereas the LPCR isn't (only) about the MMU, so mmu_model is basically just acting as a proxy for the cpu model. Handle this in a simpler way, by adding a suitable lpcr_mask to the QOM class. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2020-03-17target/ppc: Remove RMOR register from POWER9 & POWER10David Gibson
Currently we create the Real Mode Offset Register (RMOR) on all Book3S cpus from POWER7 onwards. However the translation mode which the RMOR controls is no longer supported in POWER9, and so the register has been removed from the architecture. Remove it from our model on POWER9 and POWER10. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org>
2020-03-17spapr, ppc: Remove VPM0/RMLS hacks for POWER9David Gibson
For the "pseries" machine, we use "virtual hypervisor" mode where we only model the CPU in non-hypervisor privileged mode. This means that we need guest physical addresses within the modelled cpu to be treated as absolute physical addresses. We used to do that by clearing LPCR[VPM0] and setting LPCR[RMLS] to a high limit so that the old offset based translation for guest mode applied, which does what we need. However, POWER9 has removed support for that translation mode, which meant we had some ugly hacks to keep it working. We now explicitly handle this sort of translation for virtual hypervisor mode, so the hacks aren't necessary. We don't need to set VPM0 and RMLS from the machine type code - they're now ignored in vhyp mode. On the cpu side we don't need to allow LPCR[RMLS] to be set on POWER9 in vhyp mode - that was only there to allow the hack on the machine side. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org>
2020-03-17target/ppc: Introduce ppc_hash64_use_vrma() helperDavid Gibson
When running guests under a hypervisor, the hypervisor obviously needs to be protected from guest accesses even if those are in what the guest considers real mode (translation off). The POWER hardware provides two ways of doing that: The old way has guest real mode accesses simply offset and bounds checked into host addresses. It works, but requires that a significant chunk of the guest's memory - the RMA - be physically contiguous in the host, which is pretty inconvenient. The new way, known as VRMA, has guest real mode accesses translated in roughly the normal way but with some special parameters. In POWER7 and POWER8 the LPCR[VPM0] bit selected between the two modes, but in POWER9 only VRMA mode is supported and LPCR[VPM0] no longer exists. We handle that difference in behaviour in ppc_hash64_set_isi().. but not in other places that we blindly check LPCR[VPM0]. Correct those instances with a new helper to tell if we should be in VRMA mode. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Fabiano Rosas <farosas@linux.ibm.com> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2020-03-17target/ppc: Correct handling of real mode accesses with vhyp on hash MMUDavid Gibson
On ppc we have the concept of virtual hypervisor ("vhyp") mode, where we only model the non-hypervisor-privileged parts of the cpu. Essentially we model the hypervisor's behaviour from the point of view of a guest OS, but we don't model the hypervisor's execution. In particular, in this mode, qemu's notion of target physical address is a guest physical address from the vcpu's point of view. So accesses in guest real mode don't require translation. If we were modelling the hypervisor mode, we'd need to translate the guest physical address into a host physical address. Currently, we handle this sloppily: we rely on setting up the virtual LPCR and RMOR registers so that GPAs are simply HPAs plus an offset, which we set to zero. This is already conceptually dubious, since the LPCR and RMOR registers don't exist in the non-hypervisor portion of the CPU. It gets worse with POWER9, where RMOR and LPCR[VPM0] no longer exist at all. Clean this up by explicitly handling the vhyp case. While we're there, remove some unnecessary nesting of if statements that made the logic to select the correct real mode behaviour a bit less clear than it could be. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org>
2020-03-17ppc: Remove stub of PPC970 HID4 implementationDavid Gibson
The PowerPC 970 CPU was a cut-down POWER4, which had hypervisor capability. However, it can be (and often was) strapped into "Apple mode", where the hypervisor capabilities were disabled (essentially putting it always in hypervisor mode). That's actually the only mode of the 970 we support in qemu, and we're unlikely to change that any time soon. However, we do have a partial implementation of the 970's HID4 register which affects things only relevant for hypervisor mode. That stub is also really ugly, since it attempts to duplicate the effects of HID4 by re-encoding it into the LPCR register used in newer CPUs, but in a really confusing way. Just get rid of it. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org>
2020-03-17ppc: Remove stub support for 32-bit hypervisor modeDavid Gibson
a4f30719a8cd, way back in 2007 noted that "PowerPC hypervisor mode is not fundamentally available only for PowerPC 64" and added a 32-bit version of the MSR[HV] bit. But nothing was ever really done with that; there is no meaningful support for 32-bit hypervisor mode 13 years later. Let's stop pretending and just remove the stubs. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Fabiano Rosas <farosas@linux.ibm.com> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2020-03-17ppc: Officially deprecate the CPU "compat" propertyGreg Kurz
Server class POWER CPUs have a "compat" property, which was obsoleted by commit 7843c0d60d and replaced by a "max-cpu-compat" property on the pseries machine type. A hack was introduced so that passing "compat" to -cpu would still produce the desired effect, for the sake of backward compatibility : it strips the "compat" option from the CPU properties and applies internally it to the pseries machine. The accessors of the "compat" property were updated to do nothing but warn the user about the deprecated status when doing something like: $ qemu-system-ppc64 -global POWER9-family-powerpc64-cpu.compat=power9 qemu-system-ppc64: warning: CPU 'compat' property is deprecated and has no effect; use max-cpu-compat machine property instead This was merged during the QEMU 2.10 timeframe, a few weeks before we formalized our deprecation process. As a consequence, the "compat" property fell through the cracks and was never listed in the officialy deprecated features. We are now eight QEMU versions later, it is largely time to mention it in qemu-deprecated.texi. Also, since -global XXX-powerpc64-cpu.compat= has been emitting warnings since QEMU 2.10 and the usual way of setting CPU properties is with -cpu, completely remove the "compat" property. Keep the hack so that -cpu XXX,compat= stays functional some more time, as required by our deprecation process. The now empty powerpc_servercpu_properties[] list which was introduced for "compat" and never had any other use is removed on the way. We can re-add it in the future if the need for a server class POWER CPU specific property arises again. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <158274357799.140275.12263135811731647490.stgit@bahia.lan> [dwg: Convert from .texi to .rst to match upstream change] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-03-16WHPX: Use proper synchronization primitives while processingSunil Muthuswamy
WHPX wasn't using the proper synchronization primitives while processing async events, which can cause issues with SMP. Signed-off-by: Sunil Muthuswamy <sunilmut@microsoft.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16i386: Fix GCC warning with snprintf when HAX is enabledJulio Faracco
When HAX is enabled (--enable-hax), GCC 9.2.1 reports issues with snprintf(). Replacing old snprintf() by g_strdup_printf() fixes the problem with boundary checks of vm_id and vcpu_id and finally the warnings produced by GCC. For more details, one example of warning: CC i386-softmmu/target/i386/hax-posix.o qemu/target/i386/hax-posix.c: In function ‘hax_host_open_vm’: qemu/target/i386/hax-posix.c:124:56: error: ‘%02d’ directive output may be truncated writing between 2 and 11 bytes into a region of size 3 [-Werror=format-truncation=] 124 | snprintf(name, sizeof HAX_VM_DEVFS, "/dev/hax_vm/vm%02d", vm_id); | ^~~~ qemu/target/i386/hax-posix.c:124:41: note: directive argument in the range [-2147483648, 64] 124 | snprintf(name, sizeof HAX_VM_DEVFS, "/dev/hax_vm/vm%02d", vm_id); | ^~~~~~~~~~~~~~~~~~~~ In file included from /usr/include/stdio.h:867, from qemu/include/qemu/osdep.h:99, from qemu/target/i386/hax-posix.c:14: /usr/include/bits/stdio2.h:67:10: note: ‘__builtin___snprintf_chk’ output between 17 and 26 bytes into a destination of size 17 67 | return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 68 | __bos (__s), __fmt, __va_arg_pack ()); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Signed-off-by: Julio Faracco <jcfaracco@gmail.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16qom/object: Use common get/set uint helpersFelipe Franciosi
Several objects implemented their own uint property getters and setters, despite them being straightforward (without any checks/validations on the values themselves) and identical across objects. This makes use of an enhanced API for object_property_add_uintXX_ptr() which offers default setters. Some of these setters used to update the value even if the type visit failed (eg. because the value being set overflowed over the given type). The new setter introduces a check for these errors, not updating the value if an error occurred. The error is propagated. Signed-off-by: Felipe Franciosi <felipe@nutanix.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16WHPX: Use QEMU values for trapped CPUIDSunil Muthuswamy
Currently, WHPX is using some default values for the trapped CPUID functions. These were not in sync with the QEMU values because the CPUID values were never set with WHPX during VCPU initialization. Additionally, at the moment, WHPX doesn't support setting CPUID values in the hypervisor at runtime (i.e. after the partition has been setup). That is needed to be able to set the CPUID values in the hypervisor during VCPU init. Until that support comes, use the QEMU values for the trapped CPUIDs. Signed-off-by: Sunil Muthuswamy <sunilmut@microsoft.com> Message-Id: <SN4PR2101MB0880A8323EAD0CD0E8E2F423C0EB0@SN4PR2101MB0880.namprd21.prod.outlook.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16WHPX: TSC get and set should be dependent on VM stateSunil Muthuswamy
Currently, TSC is set as part of the VM runtime state. Setting TSC at runtime is heavy and additionally can have side effects on the guest, which are not very resilient to variances in the TSC. This patch uses the VM state to determine whether to set TSC or not. Some minor enhancements for getting TSC values as well that considers the VM state. Additionally, while setting the TSC, the partition is suspended to reduce the variance in the TSC value across vCPUs. Signed-off-by: Sunil Muthuswamy <sunilmut@microsoft.com> Message-Id: <SN4PR2101MB08804D23439166E81FF151F7C0EA0@SN4PR2101MB0880.namprd21.prod.outlook.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16misc: Replace zero-length arrays with flexible array member (manual)Philippe Mathieu-Daudé
Description copied from Linux kernel commit from Gustavo A. R. Silva (see [3]): --v-- description start --v-- The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member [1], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being unadvertenly introduced [2] to the Linux codebase from now on. --^-- description end --^-- Do the similar housekeeping in the QEMU codebase (which uses C99 since commit 7be41675f7cb). All these instances of code were found with the help of the following command (then manual analysis, without modifying structures only having a single flexible array member, such QEDTable in block/qed.h): git grep -F '[0];' [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=76497732932f [3] https://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux.git/commit/?id=17642a2fbd2c1 Inspired-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-12target/arm: kvm: Inject events at the last stage of syncBeata Michalska
KVM_SET_VCPU_EVENTS might actually lead to vcpu registers being modified. As such this should be the last step of sync to avoid potential overwriting of whatever changes KVM might have done. Signed-off-by: Beata Michalska <beata.michalska@linaro.org> Reviewed-by: Andrew Jones <drjones@redhat.com> Message-id: 20200312003401.29017-2-beata.michalska@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-03-12target/arm/kvm: Let kvm_arm_vgic_probe() return a bitmapEric Auger
Convert kvm_arm_vgic_probe() so that it returns a bitmap of supported in-kernel emulation VGIC versions instead of the max version: at the moment values can be v2 and v3. This allows to expose the case where the host GICv3 also supports GICv2 emulation. This will be useful to choose the default version in KVM accelerated mode. Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20200311131618.7187-5-eric.auger@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
generated by cgit v1.2.3 (git 2.26.2) at 2025-03-15 15:39:01 +0000