aboutsummaryrefslogtreecommitdiff
path: root/hw/intc
AgeCommit message (Collapse)AuthorFilesLines
2019-07-12xics/kvm: Always set the MASKED bit if interrupt is maskedGreg Kurz1-0/+3
The ics_set_kvm_state_one() function is called either to restore the state of an interrupt source during migration or to set the interrupt source to a default state during reset. Since always, ie. 2013, the code only sets the MASKED bit if the 'current priority' and the 'saved priority' are different. This is likely true when restoring an interrupt that had been previously masked with the ibm,int-off RTAS call. However this is always false in the case of reset since both 'current priority' and 'saved priority' are equal to 0xff, and the MASKED bit is never set. The legacy KVM XICS device gets away with that because it ends updating its internal structure the same way, whether the MASKED bit is set or the priority is 0xff. The XICS-on-XIVE device for POWER9 is different. It sticks to the KVM documentation [1] and _really_ relies on the MASKED bit to correctly set. If not, it will configure the interrupt source in the XIVE HW, even though the guest hasn't configured the interrupt yet. This disturbs the complex logic implemented in XICS-on-XIVE and may result in the loss of subsequent queued events. Always set the MASKED bit if interrupt is masked as expected by the KVM XICS-on-XIVE device. This has no impact on the legacy KVM XICS. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/virtual/kvm/devices/xics.txt Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <156217454083.559957.7359208229523652842.stgit@bahia.lan> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-07-08Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into stagingPeter Maydell1-5/+6
Bugfixes. # gpg: Signature made Fri 05 Jul 2019 21:21:52 BST # 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: ioapic: use irq number instead of vector in ioapic_eoi_broadcast hw/i386: Fix linker error when ISAPC is disabled Makefile: generate header file with the list of devices enabled target/i386: kvm: Fix when nested state is needed for migration minikconf: do not include variables from MINIKCONF_ARGS in config-all-devices.mak target/i386: fix feature check in hyperv-stub.c ioapic: clear irq_eoi when updating the ioapic redirect table entry intel_iommu: Fix unexpected unmaps during global unmap intel_iommu: Fix incorrect "end" for vtd_address_space_unmap i386/kvm: Fix build with -m32 checkpatch: do not warn for multiline parenthesized returned value pc: fix possible NULL pointer dereference in pc_machine_get_device_memory_region_size() Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-07-05ioapic: use irq number instead of vector in ioapic_eoi_broadcastLi Qiang1-5/+5
When emulating irqchip in qemu, such as following command: x86_64-softmmu/qemu-system-x86_64 -m 1024 -smp 4 -hda /home/test/test.img -machine kernel-irqchip=off --enable-kvm -vnc :0 -device edu -monitor stdio We will get a crash with following asan output: (qemu) /home/test/qemu5/qemu/hw/intc/ioapic.c:266:27: runtime error: index 35 out of bounds for type 'int [24]' ================================================================= ==113504==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61b000003114 at pc 0x5579e3c7a80f bp 0x7fd004bf8c10 sp 0x7fd004bf8c00 WRITE of size 4 at 0x61b000003114 thread T4 #0 0x5579e3c7a80e in ioapic_eoi_broadcast /home/test/qemu5/qemu/hw/intc/ioapic.c:266 #1 0x5579e3c6f480 in apic_eoi /home/test/qemu5/qemu/hw/intc/apic.c:428 #2 0x5579e3c720a7 in apic_mem_write /home/test/qemu5/qemu/hw/intc/apic.c:802 #3 0x5579e3b1e31a in memory_region_write_accessor /home/test/qemu5/qemu/memory.c:503 #4 0x5579e3b1e6a2 in access_with_adjusted_size /home/test/qemu5/qemu/memory.c:569 #5 0x5579e3b28d77 in memory_region_dispatch_write /home/test/qemu5/qemu/memory.c:1497 #6 0x5579e3a1b36b in flatview_write_continue /home/test/qemu5/qemu/exec.c:3323 #7 0x5579e3a1b633 in flatview_write /home/test/qemu5/qemu/exec.c:3362 #8 0x5579e3a1bcb1 in address_space_write /home/test/qemu5/qemu/exec.c:3452 #9 0x5579e3a1bd03 in address_space_rw /home/test/qemu5/qemu/exec.c:3463 #10 0x5579e3b8b979 in kvm_cpu_exec /home/test/qemu5/qemu/accel/kvm/kvm-all.c:2045 #11 0x5579e3ae4499 in qemu_kvm_cpu_thread_fn /home/test/qemu5/qemu/cpus.c:1287 #12 0x5579e4cbdb9f in qemu_thread_start util/qemu-thread-posix.c:502 #13 0x7fd0146376da in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x76da) #14 0x7fd01436088e in __clone (/lib/x86_64-linux-gnu/libc.so.6+0x12188e This is because in ioapic_eoi_broadcast function, we uses 'vector' to index the 's->irq_eoi'. To fix this, we should uses the irq number. Signed-off-by: Li Qiang <liq3ea@163.com> Reviewed-by: Peter Xu <peterx@redhat.com> Message-Id: <20190622002119.126834-1-liq3ea@163.com>
2019-07-05ioapic: clear irq_eoi when updating the ioapic redirect table entryLi Qiang1-0/+1
irq_eoi is used to count the number of irq injected during eoi broadcast. It should be set to 0 when updating the ioapic's redirect table entry. Suggested-by: Peter Xu <peterx@redhat.com> Signed-off-by: Li Qiang <liq3ea@163.com> Reviewed-by: Peter Xu <peterx@redhat.com> Message-Id: <20190624151635.22494-1-liq3ea@163.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-07-04target/arm: v8M: Check state of exception being returned fromPeter Maydell1-1/+13
In v8M, an attempt to return from an exception which is not active is an illegal exception return. For this purpose, exceptions which can configurably target either Secure or NonSecure are not considered to be active if they are configured for the opposite security state for the one we're trying to return from (eg attempt to return from an NS NMI but NMI targets Secure). In the pseudocode this is handled by IsActiveForState(). Detect this case rather than counting an active exception possibly of the wrong security state as being sufficient. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20190617175317.27557-4-peter.maydell@linaro.org
2019-07-04arm v8M: Forcibly clear negative-priority exceptions on deactivatePeter Maydell1-5/+35
To prevent execution priority remaining negative if the guest returns from an NMI or HardFault with a corrupted IPSR, the v8M interrupt deactivation process forces the HardFault and NMI to inactive based on the current raw execution priority, even if the interrupt the guest is trying to deactivate is something else. In the pseudocode this is done in the Deactivate() function. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20190617175317.27557-3-peter.maydell@linaro.org
2019-07-02Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-4.1-20190702' ↵Peter Maydell7-189/+333
into staging ppc patch queue 2019-07-2 Here's my next pull request for qemu-4.1. I'm not sure if this will squeak in just before the soft freeze, or just after. I don't think it really matters - most of this is bugfixes anyway. There's some cleanups which aren't stictly bugfixes, but which I think are safe enough improvements to go in the soft freeze. There's no true feature work. Unfortunately, I wasn't able to complete a few of my standard battery of pre-pull tests, due to some failures that appear to also be in master. I'm hoping that hasn't missed anything important in here. Highlights are: * A number of fixe and cleanups for the XIVE implementation * Cleanups to the XICS interrupt controller to fit better with the new XIVE code * Numerous fixes and improvements to TCG handling of ppc vector instructions * Remove a number of unnnecessary #ifdef CONFIG_KVM guards * Fix some errors in the PCI hotplug paths * Assorted other fixes # gpg: Signature made Tue 02 Jul 2019 07:07:15 BST # 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-4.1-20190702: (49 commits) spapr/xive: Add proper rollback to kvmppc_xive_connect() ppc/xive: Fix TM_PULL_POOL_CTX special operation ppc/pnv: Rework cache watch model of PnvXIVE ppc/xive: Make the PIPR register readonly ppc/xive: Force the Physical CAM line value to group mode spapr/xive: simplify spapr_irq_init_device() to remove the emulated init spapr/xive: rework the mapping the KVM memory regions spapr_pci: Unregister listeners before destroying the IOMMU address space target/ppc: improve VSX_FMADD with new GEN_VSX_HELPER_VSX_MADD macro target/ppc: decode target register in VSX_EXTRACT_INSERT at translation time target/ppc: decode target register in VSX_VECTOR_LOAD_STORE_LENGTH at translation time target/ppc: introduce GEN_VSX_HELPER_R2_AB macro to fpu_helper.c target/ppc: introduce GEN_VSX_HELPER_R2 macro to fpu_helper.c target/ppc: introduce GEN_VSX_HELPER_R3 macro to fpu_helper.c target/ppc: introduce GEN_VSX_HELPER_X1 macro to fpu_helper.c target/ppc: introduce GEN_VSX_HELPER_X2_AB macro to fpu_helper.c target/ppc: introduce GEN_VSX_HELPER_X2 macro to fpu_helper.c target/ppc: introduce separate generator and helper for xscvqpdp target/ppc: introduce GEN_VSX_HELPER_X3 macro to fpu_helper.c target/ppc: introduce separate VSX_CMP macro for xvcmp* instructions ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-07-02spapr/xive: Add proper rollback to kvmppc_xive_connect()Greg Kurz1-19/+29
Make kvmppc_xive_disconnect() able to undo the changes of a partial execution of kvmppc_xive_connect() and use it to perform rollback. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <156198735673.293938.7313195993600841641.stgit@bahia> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-07-02ppc/xive: Fix TM_PULL_POOL_CTX special operationCédric Le Goater1-9/+10
When a CPU is reseted, the hypervisor (Linux or OPAL) invalidates the POOL interrupt context of a CPU with this special command. It returns the POOL CAM line value and resets the VP bit. Fixes: 4836b45510aa ("ppc/xive: activate HV support") Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20190630204601.30574-5-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-07-02ppc/pnv: Rework cache watch model of PnvXIVECédric Le Goater1-36/+106
When the software modifies the XIVE internal structures, ESB, EAS, END, NVT, it also must update the caches of the different XIVE sub-engines. HW offers a set of common interface for such purpose. The CWATCH_SPEC register defines the block/index of the target and a set of flags to perform a full update and to watch for update conflicts. The cache watch CWATCH_DATAX registers are then loaded with the target data with a first read on CWATCH_DATA0. Writing back is done in the opposit order, CWATCH_DATA0 triggering the update. The SCRUB_TRIG registers are used to flush the cache in RAM, and to possibly invalidate it. Cache disablement is also an option but as we do not model the cache, these registers are no-ops Today, the modeling of these registers is incorrect but it did not impact the set up of a baremetal system. However, running KVM requires a rework. Fixes: 2dfa91a2aa5a ("ppc/pnv: add a XIVE interrupt controller model for POWER9") Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20190630204601.30574-4-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-07-02ppc/xive: Make the PIPR register readonlyCédric Le Goater1-16/+16
When the hypervisor (KVM) dispatches a vCPU on a HW thread, it restores its thread interrupt context. The Pending Interrupt Priority Register (PIPR) is computed from the Interrupt Pending Buffer (IPB) and stores should not be allowed to change its value. Fixes: 207d9fe98510 ("ppc/xive: introduce the XIVE interrupt thread context") Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20190630204601.30574-3-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-07-02ppc/xive: Force the Physical CAM line value to group modeCédric Le Goater1-16/+5
When an interrupt needs to be delivered, the XIVE interrupt controller presenter scans the CAM lines of the thread interrupt contexts of the HW threads of the chip to find a matching vCPU. The interrupt context is composed of 4 different sets of registers: Physical, HV, OS and User. The encoding of the Physical CAM line depends on the mode in which the interrupt controller is operating: CAM mode or block group mode. Block group mode being the default configuration today on POWER9 and the only one available on the next POWER10 generation, enforce this encoding in the Physical CAM line : chip << 19 | 0000000 0 0001 thread (7Bit) It fits the overall encoding of the NVT ids and simplifies the matching algorithm in the presenter. Fixes: d514c48d41fb ("ppc/xive: hardwire the Physical CAM line of the thread context") Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20190630204601.30574-2-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-07-02spapr/xive: rework the mapping the KVM memory regionsCédric Le Goater2-37/+22
Today, the interrupt device is fully initialized at reset when the CAS negotiation process has completed. Depending on the KVM capabilities, the SpaprXive memory regions (ESB, TIMA) are initialized with a host MMIO backend or a QEMU emulated backend. This results in a complex initialization sequence partially done at realize and later at reset, and some memory region leaks. To simplify this sequence and to remove of the late initialization of the emulated device which is required to be done only once, we introduce new memory regions specific for KVM. These regions are mapped as overlaps on top of the emulated device to make use of the host MMIOs. Also provide proper cleanups of these regions when the XIVE KVM device is destroyed to fix the leaks. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20190614165920.12670-2-clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-07-02xics/kvm: Add proper rollback to xics_kvm_init()Greg Kurz1-6/+5
Make xics_kvm_disconnect() able to undo the changes of a partial execution of xics_kvm_connect() and use it to perform rollback. Note that kvmppc_define_rtas_kernel_token(0) never fails, no matter the RTAS call has been defined or not. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <156077922319.433243.609897156640506891.stgit@bahia.lan> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-07-02xics/kvm: Add error propagation to ic*_set_kvm_state() functionsGreg Kurz2-20/+56
This allows errors happening there to be propagated up to spapr_irq, just like XIVE already does. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <156077921763.433243.4614327010172954196.stgit@bahia.lan> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-07-02xics/kvm: Always use local_err in xics_kvm_init()Greg Kurz1-6/+10
Passing both errp and &local_err to functions is a recipe for messing things up. Since we must use &local_err for icp_kvm_realize(), use &local_err everywhere where rollback must happen and have a single call to error_propagate() them all. While here, add errno to the error message. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <156077921212.433243.11716701611944816815.stgit@bahia.lan> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-07-02xics/kvm: Skip rollback when KVM XICS is absentGreg Kurz1-1/+1
There is no need to rollback anything at this point, so just return an error. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <156077920657.433243.13541093940589972734.stgit@bahia.lan> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-07-02xics/spapr: Rename xics_kvm_init()Greg Kurz1-1/+1
Switch to using the connect/disconnect terminology like we already do for XIVE. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <156077920102.433243.6605099291134598170.stgit@bahia.lan> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-07-02xics/spapr: Only emulated XICS should use RTAS/hypercalls emulationGreg Kurz1-26/+27
Checking that we're not using the in-kernel XICS is ok with the "xics" interrupt controller mode, but it is definitely not enough with the other modes since the guest could be using XIVE. Ensure XIVE is not in use when emulated XICS RTAS/hypercalls are called. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <156077253666.424706.6104557911104491047.stgit@bahia.lan> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-07-02xics: Add comment about CPU hotplugGreg Kurz1-0/+1
So that no one is tempted to drop that code, which is never called for cold plugged CPUs. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <156078063349.435533.12283208810037409702.stgit@bahia.lan> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-07-02xics/spapr: Detect old KVM XICS on POWER9 hostsGreg Kurz1-0/+30
Older KVMs on POWER9 don't support destroying/recreating a KVM XICS device, which is required by 'dual' interrupt controller mode. This causes QEMU to emit a warning when the guest is rebooted and to fall back on XICS emulation: qemu-system-ppc64: warning: kernel_irqchip allowed but unavailable: Error on KVM_CREATE_DEVICE for XICS: File exists If kernel irqchip is required, QEMU will thus exit when the guest is first rebooted. Failing QEMU this late may be a painful experience for the user. Detect that and exit at machine init instead. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <156044430517.125694.6207865998817342638.stgit@bahia.lab.toulouse-stg.fr.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-07-02xics/spapr: Register RTAS/hypercalls once at machine initGreg Kurz2-27/+0
QEMU may crash when running a spapr machine in 'dual' interrupt controller mode on some older (but not that old, eg. ubuntu 18.04.2) KVMs with partial XIVE support: qemu-system-ppc64: hw/ppc/spapr_rtas.c:411: spapr_rtas_register: Assertion `!name || !rtas_table[token].name' failed. XICS is controlled by the guest thanks to a set of RTAS calls. Depending on whether KVM XICS is used or not, the RTAS calls are handled by KVM or QEMU. In both cases, QEMU needs to expose the RTAS calls to the guest through the "rtas" node of the device tree. The spapr_rtas_register() helper takes care of all of that: it adds the RTAS call token to the "rtas" node and registers a QEMU callback to be invoked when the guest issues the RTAS call. In the KVM XICS case, QEMU registers a dummy callback that just prints an error since it isn't supposed to be invoked, ever. Historically, the XICS controller was setup during machine init and released during final teardown. This changed when the 'dual' interrupt controller mode was added to the spapr machine: in this case we need to tear the XICS down and set it up again during machine reset. The crash happens because we indeed have an incompatibility with older KVMs that forces QEMU to fallback on emulated XICS, which tries to re-registers the same RTAS calls. This could be fixed by adding proper rollback that would unregister RTAS calls on error. But since the emulated RTAS calls in QEMU can now detect when they are mistakenly called while KVM XICS is in use, it seems simpler to register them once and for all at machine init. This fixes the crash and allows to remove some now useless lines of code. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <156044429963.125694.13710679451927268758.stgit@bahia.lab.toulouse-stg.fr.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-07-02xics/spapr: Prevent RTAS/hypercalls emulation to be used by in-kernel XICSGreg Kurz1-0/+46
The XICS-related RTAS calls and hypercalls in QEMU are not supposed to be called when the KVM in-kernel XICS is in use. Add some explicit checks to detect that, print an error message and report an hardware error to the guest. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <156044429419.125694.507569071972451514.stgit@bahia.lab.toulouse-stg.fr.ibm.com> [dwg: Correction to commit message] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-07-02ppc/pnv: fix StoreEOI activationCédric Le Goater1-2/+1
The firmware (skiboot) of the PowerNV machines can configure the XIVE interrupt controller to activate StoreEOI on the ESB pages of the interrupts. This feature lets software do an EOI with a store instead of a load. It is not activated today on P9 for rare race condition issues but it should be on future processors. Nevertheless, QEMU has a model for StoreEOI which can be used today by experimental firmwares. But, the use of object_property_set_int() in the PnvXive model is incorrect and crashes QEMU. Replace it with a direct access to the ESB flags of the XiveSource object modeling the internal sources of the interrupt controller. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20190612162357.29566-1-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-07-01aspeed: vic: Add support for legacy register interfaceAndrew Jeffery1-42/+63
The legacy interface only supported up to 32 IRQs, which became restrictive around the AST2400 generation. QEMU support for the SoCs started with the AST2400 along with an effort to reimplement and upstream drivers for Linux, so up until this point the consumers of the QEMU ASPEED support only required the 64 IRQ register interface. In an effort to support older BMC firmware, add support for the 32 IRQ interface. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Joel Stanley <joel@jms.id.au> Message-id: 20190618165311.27066-22-clg@kaod.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-06-17hw/intc/arm_gicv3: GICD_TYPER.SecurityExtn is RAZ if GICD_CTLR.DS == 1Peter Maydell1-1/+7
The GICv3 specification says that the GICD_TYPER.SecurityExtn bit is RAZ if GICD_CTLR.DS is 1. We were incorrectly making it RAZ if the security extension is unsupported. "Security extension unsupported" always implies GICD_CTLR.DS == 1, but the guest can also set DS on a GIC which does support the security extension. Fix the condition to correctly check the GICD_CTLR.DS bit. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20190524124248.28394-3-peter.maydell@linaro.org
2019-06-17hw/intc/arm_gicv3: Fix decoding of ID register rangePeter Maydell2-4/+4
The GIC ID registers cover an area 0x30 bytes in size (12 registers, 4 bytes each). We were incorrectly decoding only the first 0x20 bytes. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190524124248.28394-2-peter.maydell@linaro.org
2019-06-12Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-4.1-20190612' ↵Peter Maydell1-3/+19
into staging ppc patch queue 2019-06-12 Next pull request against qemu-4.1. The big thing here is adding support for hot plug of P2P bridges, and PCI devices under P2P bridges on the "pseries" machine (which doesn't use SHPC). Other than that there's just a handful of fixes and small enhancements. # gpg: Signature made Wed 12 Jun 2019 06:47:56 BST # 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-4.1-20190612: ppc/xive: Make XIVE generate the proper interrupt types ppc/pnv: activate the "dumpdtb" option on the powernv machine target/ppc: Use tcg_gen_gvec_bitsel spapr: Allow hot plug/unplug of PCI bridges and devices under PCI bridges spapr: Direct all PCI hotplug to host bridge, rather than P2P bridge spapr: Don't use bus number for building DRC ids spapr: Clean up DRC index construction spapr: Clean up spapr_drc_populate_dt() spapr: Clean up dt creation for PCI buses spapr: Clean up device tree construction for PCI devices spapr: Clean up device node name generation for PCI devices target/ppc: Fix lxvw4x, lxvh8x and lxvb16x spapr_pci: Improve error message Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-06-12Include qemu-common.h exactly where neededMarkus Armbruster2-2/+0
No header includes qemu-common.h after this commit, as prescribed by qemu-common.h's file comment. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190523143508.25387-5-armbru@redhat.com> [Rebased with conflicts resolved automatically, except for include/hw/arm/xlnx-zynqmp.h hw/arm/nrf51_soc.c hw/arm/msf2-soc.c block/qcow2-refcount.c block/qcow2-cluster.c block/qcow2-cache.c target/arm/cpu.h target/lm32/cpu.h target/m68k/cpu.h target/mips/cpu.h target/moxie/cpu.h target/nios2/cpu.h target/openrisc/cpu.h target/riscv/cpu.h target/tilegx/cpu.h target/tricore/cpu.h target/unicore32/cpu.h target/xtensa/cpu.h; bsd-user/main.c and net/tap-bsd.c fixed up]
2019-06-12Include qemu/module.h where needed, drop it from qemu-common.hMarkus Armbruster44-8/+49
Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190523143508.25387-4-armbru@redhat.com> [Rebased with conflicts resolved automatically, except for hw/usb/dev-hub.c hw/misc/exynos4210_rng.c hw/misc/bcm2835_rng.c hw/misc/aspeed_scu.c hw/display/virtio-vga.c hw/arm/stm32f205_soc.c; ui/cocoa.m fixed up]
2019-06-12ppc/xive: Make XIVE generate the proper interrupt typesBenjamin Herrenschmidt1-3/+19
It should be generic Hypervisor Virtualization interrupts for HV directed rings and traditional External Interrupts for the OS directed ring. Don't generate anything for the user ring as it isn't actually supported. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20190606174409.12502-1-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-06-10target/mips: Use env_cpu, env_archcpuRichard Henderson1-1/+1
Cleanup in the boilerplate that each target must define. Replace mips_env_get_cpu with env_archcpu. The combination CPU(mips_env_get_cpu) should have used ENV_GET_CPU to begin; use env_cpu now. Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2019-05-29spapr/xive: fix multiple resets when using the 'dual' interrupt modeCédric Le Goater2-10/+5
Today, when a reset occurs on a pseries machine using the 'dual' interrupt mode, the KVM devices are released and recreated depending on the interrupt mode selected by CAS. If XIVE is selected, the SysBus memory regions of the SpaprXive model are initialized by the KVM backend initialization routine each time a reset occurs. This leads to a crash after a couple of resets because the machine reaches the QDEV_MAX_MMIO limit of SysBusDevice : qemu-system-ppc64: hw/core/sysbus.c:193: sysbus_init_mmio: Assertion `dev->num_mmio < QDEV_MAX_MMIO' failed. To fix, initialize the SysBus memory regions in spapr_xive_realize() called only once and remove the same inits from the QEMU and KVM backend initialization routines which are called at each reset. Reported-by: Satheesh Rajendran <sathnaga@linux.vnet.ibm.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20190522074016.10521-2-clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-05-29spapr/irq: add KVM support to the 'dual' machineCédric Le Goater3-5/+59
The interrupt mode is chosen by the CAS negotiation process and activated after a reset to take into account the required changes in the machine. This brings new constraints on how the associated KVM IRQ device is initialized. Currently, each model takes care of the initialization of the KVM device in their realize method but this is not possible anymore as the initialization needs to be done globaly when the interrupt mode is known, i.e. when machine is reseted. It also means that we need a way to delete a KVM device when another mode is chosen. Also, to support migration, the QEMU objects holding the state to transfer should always be available but not necessarily activated. The overall approach of this proposal is to initialize both interrupt mode at the QEMU level to keep the IRQ number space in sync and to allow switching from one mode to another. For the KVM side of things, the whole initialization of the KVM device, sources and presenters, is grouped in a single routine. The XICS and XIVE sPAPR IRQ reset handlers are modified accordingly to handle the init and the delete sequences of the KVM device. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20190513084245.25755-15-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-05-29ppc/xics: fix irq priority in ics_set_irq_type()Cédric Le Goater1-2/+8
Recent commits changed the behavior of ics_set_irq_type() to initialize correctly LSIs at the KVM level. ics_set_irq_type() is also called by the realize routine of the different devices of the machine when initial interrupts are claimed, before the ICSState device is reseted. In the case, the ICSIRQState priority is 0x0 and the call to ics_set_irq_type() results in configuring the target of the interrupt. On P9, when using the KVM XICS-on-XIVE device, the target is configured to be server 0, priority 0 and the event queue 0 is created automatically by KVM. With the dual interrupt mode creating the KVM device at reset, it leads to unexpected effects on the guest, mostly blocking IPIs. This is wrong, fix it by reseting the ICSIRQState structure when ics_set_irq_type() is called. Fixes: commit 6cead90c5c9c ("xics: Write source state to KVM at claim time") Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20190513084245.25755-14-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-05-29spapr/irq: initialize the IRQ device only onceCédric Le Goater2-0/+16
Add a check to make sure that the routine initializing the emulated IRQ device is called once. We don't have much to test on the XICS side, so we introduce a 'init' boolean under ICSState. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20190513084245.25755-13-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-05-29spapr/irq: introduce a spapr_irq_init_device() helperCédric Le Goater1-21/+5
The way the XICS and the XIVE devices are initialized follows the same pattern. First, try to connect to the KVM device and if not possible fallback on the emulated device, unless a kernel_irqchip is required. The spapr_irq_init_device() routine implements this sequence in generic way using new sPAPR IRQ handlers ->init_emu() and ->init_kvm(). The XIVE init sequence is moved under the associated sPAPR IRQ ->init() handler. This will change again when KVM support is added for the dual interrupt mode. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20190513084245.25755-12-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-05-29spapr: check for the activation of the KVM IRQ deviceCédric Le Goater2-1/+63
The activation of the KVM IRQ device depends on the interrupt mode chosen at CAS time by the machine and some methods used at reset or by the migration need to be protected. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20190513084245.25755-11-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-05-29spapr: introduce routines to delete the KVM IRQ deviceCédric Le Goater2-0/+107
If a new interrupt mode is chosen by CAS, the machine generates a reset to reconfigure. At this point, the connection with the previous KVM device needs to be closed and a new connection needs to opened with the KVM device operating the chosen interrupt mode. New routines are introduced to destroy the XICS and the XIVE KVM devices. They make use of a new KVM device ioctl which destroys the device and also disconnects the IRQ presenters from the vCPUs. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20190513084245.25755-10-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-05-29spapr/xive: add migration support for KVMCédric Le Goater3-1/+135
When the VM is stopped, the VM state handler stabilizes the XIVE IC and marks the EQ pages dirty. These are then transferred to destination before the transfer of the device vmstates starts. The SpaprXive interrupt controller model captures the XIVE internal tables, EAT and ENDT and the XiveTCTX model does the same for the thread interrupt context registers. At restart, the SpaprXive 'post_load' method restores all the XIVE states. It is called by the sPAPR machine 'post_load' method, when all XIVE states have been transferred and loaded. Finally, the source states are restored in the VM change state handler when the machine reaches the running state. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20190513084245.25755-7-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-05-29spapr/xive: introduce a VM state change handlerCédric Le Goater1-1/+95
This handler is in charge of stabilizing the flow of event notifications in the XIVE controller before migrating a guest. This is a requirement before transferring the guest EQ pages to a destination. When the VM is stopped, the handler sets the source PQs to PENDING to stop the flow of events and to possibly catch a triggered interrupt occuring while the VM is stopped. Their previous state is saved. The XIVE controller is then synced through KVM to flush any in-flight event notification and to stabilize the EQs. At this stage, the EQ pages are marked dirty to make sure the EQ pages are transferred if a migration sequence is in progress. The previous configuration of the sources is restored when the VM resumes, after a migration or a stop. If an interrupt was queued while the VM was stopped, the handler simply generates the missing trigger. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20190513084245.25755-6-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-05-29spapr/xive: add state synchronization with KVMCédric Le Goater3-7/+110
This extends the KVM XIVE device backend with 'synchronize_state' methods used to retrieve the state from KVM. The HW state of the sources, the KVM device and the thread interrupt contexts are collected for the monitor usage and also migration. These get operations rely on their KVM counterpart in the host kernel which acts as a proxy for OPAL, the host firmware. The set operations will be added for migration support later. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20190513084245.25755-5-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-05-29spapr/xive: add hcall support when under KVMCédric Le Goater2-8/+279
XIVE hcalls are all redirected to QEMU as none are on a fast path. When necessary, QEMU invokes KVM through specific ioctls to perform host operations. QEMU should have done the necessary checks before calling KVM and, in case of failure, H_HARDWARE is simply returned. H_INT_ESB is a special case that could have been handled under KVM but the impact on performance was low when under QEMU. Here are some figures : kernel irqchip OFF ON H_INT_ESB KVM QEMU rtl8139 (LSI ) 1.19 1.24 1.23 Gbits/sec virtio 31.80 42.30 -- Gbits/sec Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20190513084245.25755-4-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-05-29spapr/xive: add KVM supportCédric Le Goater4-9/+298
This introduces a set of helpers when KVM is in use, which create the KVM XIVE device, initialize the interrupt sources at a KVM level and connect the interrupt presenters to the vCPU. They also handle the initialization of the TIMA and the source ESB memory regions of the controller. These have a different type under KVM. They are 'ram device' memory mappings, similarly to VFIO, exposed to the guest and the associated VMAs on the host are populated dynamically with the appropriate pages using a fault handler. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20190513084245.25755-3-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-05-29Fix typo on "info pic" monitor cmd output for xiveSatheesh Rajendran1-1/+1
Instead of LISN i.e "Logical Interrupt Source Number" as per Xive PAPR document "info pic" prints as LSIN, let's fix it. Signed-off-by: Satheesh Rajendran <sathnaga@linux.vnet.ibm.com> Message-Id: <20190509080750.21999-1-sathnaga@linux.vnet.ibm.com> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-05-29spapr/xive: print out the EQ page address in the monitorCédric Le Goater1-2/+3
This proved to be a useful information when debugging issues with OS event queues allocated above 64GB. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20190508171946.657-4-clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-05-29spapr/xive: fix EQ page addresses above 64GBCédric Le Goater2-8/+4
The high order bits of the address of the OS event queue is stored in bits [4-31] of word2 of the XIVE END internal structures and the low order bits in word3. This structure is using Big Endian ordering and computing the value requires some simple arithmetic which happens to be wrong. The mask removing bits [0-3] of word2 is applied to the wrong value and the resulting address is bogus when above 64GB. Guests with more than 64GB of RAM will allocate pages for the OS event queues which will reside above the 64GB limit. In this case, the XIVE device model will wake up the CPUs in case of a notification, such as IPIs, but the update of the event queue will be written at the wrong place in memory. The result is uncertain as the guest memory is trashed and IPI are not delivered. Introduce a helper xive_end_qaddr() to compute this value correctly in all places where it is used. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20190508171946.657-3-clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-05-29spapr/xive: EQ page should be naturally alignedCédric Le Goater1-0/+6
When the OS configures the EQ page in which to receive event notifications from the XIVE interrupt controller, the page should be naturally aligned. Add this check. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20190508171946.657-2-clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org> [dwg: Minor change for printf warning on some platforms] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-05-24hw/intc/nvic: Use object_initialize_child for correct reference countingPhilippe Mathieu-Daudé1-3/+3
As explained in commit aff39be0ed97: Both functions, object_initialize() and object_property_add_child() increase the reference counter of the new object, so one of the references has to be dropped afterwards to get the reference counting right. Otherwise the child object will not be properly cleaned up when the parent gets destroyed. Thus let's use now object_initialize_child() instead to get the reference counting here right. This patch was generated using the following Coccinelle script: @use_sysbus_init_child_obj_missing_parent@ expression child_ptr; expression child_type; expression child_size; @@ - object_initialize(child_ptr, child_size, child_type); ... - qdev_set_parent_bus(DEVICE(child_ptr), sysbus_get_default()); ... ?- object_unref(OBJECT(child_ptr)); + sysbus_init_child_obj(OBJECT(PARENT_OBJ), "CHILD_NAME", child_ptr, + child_size, child_type); We let NVIC adopt the SysTick timer. While the object_initialize() function doesn't take an 'Error *errp' argument, the object_initialize_child() does. Since this code is used when a machine is created (and is not yet running), we deliberately choose to use the &error_abort argument instead of ignoring errors if an object creation failed. This choice also matches when using sysbus_init_child_obj(), since its code is: void sysbus_init_child_obj(Object *parent, const char *childname, void *child, size_t childsize, const char *childtype) { object_initialize_child(parent, childname, child, childsize, childtype, &error_abort, NULL); qdev_set_parent_bus(DEVICE(child), sysbus_get_default()); } Suggested-by: Eduardo Habkost <ehabkost@redhat.com> Inspired-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20190507163416.24647-17-philmd@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2019-05-23hw/intc/arm_gicv3: Fix writes to ICC_CTLR_EL3Peter Maydell1-2/+2
The ICC_CTLR_EL3 register includes some bits which are aliases of bits in the ICC_CTLR_EL1(S) and (NS) registers. QEMU chooses to keep those bits in the cs->icc_ctlr_el1[] struct fields. Unfortunately a missing '~' in the code to update the bits in those fields meant that writing to ICC_CTLR_EL3 would corrupt the ICC_CLTR_EL1 register values. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190520162809.2677-5-peter.maydell@linaro.org
generated by cgit v1.1 at 2025-01-11 05:54:39 +0000