aboutsummaryrefslogtreecommitdiff
path: root/hw/intc
AgeCommit message (Collapse)AuthorFilesLines
2020-05-15qdev: Unrealize must not failMarkus Armbruster4-5/+5
Devices may have component devices and buses. Device realization may fail. Realization is recursive: a device's realize() method realizes its components, and device_set_realized() realizes its buses (which should in turn realize the devices on that bus, except bus_set_realized() doesn't implement that, yet). When realization of a component or bus fails, we need to roll back: unrealize everything we realized so far. If any of these unrealizes failed, the device would be left in an inconsistent state. Must not happen. device_set_realized() lets it happen: it ignores errors in the roll back code starting at label child_realize_fail. Since realization is recursive, unrealization must be recursive, too. But how could a partly failed unrealize be rolled back? We'd have to re-realize, which can fail. This design is fundamentally broken. device_set_realized() does not roll back at all. Instead, it keeps unrealizing, ignoring further errors. It can screw up even for a device with no buses: if the lone dc->unrealize() fails, it still unregisters vmstate, and calls listeners' unrealize() callback. bus_set_realized() does not roll back either. Instead, it stops unrealizing. Fortunately, no unrealize method can fail, as we'll see below. To fix the design error, drop parameter @errp from all the unrealize methods. Any unrealize method that uses @errp now needs an update. This leads us to unrealize() methods that can fail. Merely passing it to another unrealize method cannot cause failure, though. Here are the ones that do other things with @errp: * virtio_serial_device_unrealize() Fails when qbus_set_hotplug_handler() fails, but still does all the other work. On failure, the device would stay realized with its resources completely gone. Oops. Can't happen, because qbus_set_hotplug_handler() can't actually fail here. Pass &error_abort to qbus_set_hotplug_handler() instead. * hw/ppc/spapr_drc.c's unrealize() Fails when object_property_del() fails, but all the other work is already done. On failure, the device would stay realized with its vmstate registration gone. Oops. Can't happen, because object_property_del() can't actually fail here. Pass &error_abort to object_property_del() instead. * spapr_phb_unrealize() Fails and bails out when remove_drcs() fails, but other work is already done. On failure, the device would stay realized with some of its resources gone. Oops. remove_drcs() fails only when chassis_from_bus()'s object_property_get_uint() fails, and it can't here. Pass &error_abort to remove_drcs() instead. Therefore, no unrealize method can fail before this patch. device_set_realized()'s recursive unrealization via bus uses object_property_set_bool(). Can't drop @errp there, so pass &error_abort. We similarly unrealize with object_property_set_bool() elsewhere, always ignoring errors. Pass &error_abort instead. Several unrealize methods no longer handle errors from other unrealize methods: virtio_9p_device_unrealize(), virtio_input_device_unrealize(), scsi_qdev_unrealize(), ... Much of the deleted error handling looks wrong anyway. One unrealize methods no longer ignore such errors: usb_ehci_pci_exit(). Several realize methods no longer ignore errors when rolling back: v9fs_device_realize_common(), pci_qdev_unrealize(), spapr_phb_realize(), usb_qdev_realize(), vfio_ccw_realize(), virtio_device_realize(). Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20200505152926.18877-17-armbru@redhat.com>
2020-05-15qom: Drop parameter @errp of object_property_add() & friendsMarkus Armbruster4-5/+5
The only way object_property_add() can fail is when a property with the same name already exists. Since our property names are all hardcoded, failure is a programming error, and the appropriate way to handle it is passing &error_abort. Same for its variants, except for object_property_add_child(), which additionally fails when the child already has a parent. Parentage is also under program control, so this is a programming error, too. We have a bit over 500 callers. Almost half of them pass &error_abort, slightly fewer ignore errors, one test case handles errors, and the remaining few callers pass them to their own callers. The previous few commits demonstrated once again that ignoring programming errors is a bad idea. Of the few ones that pass on errors, several violate the Error API. The Error ** argument must be NULL, &error_abort, &error_fatal, or a pointer to a variable containing NULL. Passing an argument of the latter kind twice without clearing it in between is wrong: if the first call sets an error, it no longer points to NULL for the second call. ich9_pm_add_properties(), sparc32_ledma_realize(), sparc32_dma_realize(), xilinx_axidma_realize(), xilinx_enet_realize() are wrong that way. When the one appropriate choice of argument is &error_abort, letting users pick the argument is a bad idea. Drop parameter @errp and assert the preconditions instead. There's one exception to "duplicate property name is a programming error": the way object_property_add() implements the magic (and undocumented) "automatic arrayification". Don't drop @errp there. Instead, rename object_property_add() to object_property_try_add(), and add the obvious wrapper object_property_add(). Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20200505152926.18877-15-armbru@redhat.com> [Two semantic rebase conflicts resolved]
2020-04-30bugfix: Use gicr_typer in arm_gicv3_icc_resetKeqian Zhu1-3/+1
The KVM_VGIC_ATTR macro expect the second parameter as gicr_typer, of which high 32bit is constructed by mp_affinity. For most case, the high 32bit of mp_affinity is zero, so it will always access the ICC_CTLR_EL1 of CPU0. Signed-off-by: Keqian Zhu <zhukeqian1@huawei.com> Message-id: 20200413091552.62748-2-zhukeqian1@huawei.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-03-23hw/arm/bcm283x: Correct the license textPhilippe Mathieu-Daudé2-3/+5
The license is the 'GNU General Public License v2.0 or later', not 'and': This program is free software; you can redistribute it and/ori modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. Fix the license comment. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20200312213455.15854-1-philmd@redhat.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-03-17spapr/xive: use SPAPR_IRQ_IPI to define IPI ranges exposed to the guestCédric Le Goater1-2/+2
The "ibm,xive-lisn-ranges" defines ranges of interrupt numbers that the guest can use to configure IPIs. It starts at 0 today but it could change to some other offset. Make clear which IRQ range we are exposing by using SPAPR_IRQ_IPI in the property definition. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20200306123307.1348-1-clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-03-12hw/intc/armv7m_nvic: Rebuild hflags on resetPeter Maydell1-0/+6
Some of an M-profile CPU's cached hflags state depends on state that's in our NVIC object. We already do an hflags rebuild when the NVIC registers are written, but we also need to do this on NVIC reset, because there's no guarantee that this will happen before the CPU reset. This fixes an assertion due to mismatched hflags which happens if the CPU is reset from inside a HardFault handler. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20200303174950.3298-2-peter.maydell@linaro.org
2020-02-28hw/intc/arm_gic_kvm: Don't assume kernel can provide a GICv2Peter Maydell1-0/+9
In our KVM GICv2 realize function, we try to cope with old kernels that don't provide the device control API (KVM_CAP_DEVICE_CTRL): we try to use the device control, and if that fails we fall back to assuming that the kernel has the old style KVM_CREATE_IRQCHIP and that it will provide a GICv2. This doesn't cater for the possibility of a kernel and hardware which only provide a GICv3, which is very common now. On that setup we will abort() later on in kvm_arm_pmu_set_irq() when we try to wire up an interrupt to the GIC we failed to create: qemu-system-aarch64: PMU: KVM_SET_DEVICE_ATTR: Invalid argument qemu-system-aarch64: failed to set irq for PMU Aborted If the kernel advertises KVM_CAP_DEVICE_CTRL we should trust it if it says it can't create a GICv2, rather than assuming it has one. We can then produce a more helpful error message including a hint about the most probable reason for the failure. If the kernel doesn't advertise KVM_CAP_DEVICE_CTRL then it is truly ancient by this point but we might as well still fall back to a KVM_CREATE_IRQCHIP GICv2. With this patch then the user misconfiguration which previously caused an abort now prints: qemu-system-aarch64: Initialization of device kvm-arm-gic failed: error creating in-kernel VGIC: No such device Perhaps the host CPU does not support GICv2? Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Andrew Jones <drjones@redhat.com> Tested-by: Andrew Jones <drjones@redhat.com> Message-id: 20200225182435.1131-1-peter.maydell@linaro.org
2020-02-28target/arm: Add isar_feature_aa32_vfp_simdRichard Henderson1-10/+10
Use this in the places that were checking ARM_FEATURE_VFP, and are obviously testing for the existance of the register set as opposed to testing for some particular instruction extension. Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20200224222232.13807-2-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-28arm_gic: Mask the un-supported priority bitsSai Pavan Boddu2-2/+32
The GICv2 allows the implementation to implement a variable number of priority bits; unimplemented bits in the priority registers are read as zeros, writes ignored. We were previously always implementing a full 8 bits of priority, which is allowed but not what the real hardware typically does (which is usually to have 4 or 5 bits of priority). Add a new device property to allow the number of implemented property bits to be specified. Signed-off-by: Sai Pavan Boddu <sai.pavan.boddu@xilinx.com> Message-id: 1582537164-764-2-git-send-email-sai.pavan.boddu@xilinx.com Suggested-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> [PMM: improved commit message] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-21target/arm: Test correct register in aa32_pan and aa32_ats1e1 checksPeter Maydell1-4/+4
The isar_feature_aa32_pan and isar_feature_aa32_ats1e1 functions are supposed to be testing fields in ID_MMFR3; but a cut-and-paste error meant we were looking at MVFR0 instead. Fix the functions to look at the right register; this requires us to move at least id_mmfr3 to the ARMISARegisters struct; we choose to move all the ID_MMFRn registers for consistency. Fixes: 3d6ad6bb466f Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20200214175116.9164-19-peter.maydell@linaro.org
2020-02-21target/arm: Define an aa32_pmu_8_1 isar feature test functionPeter Maydell1-1/+1
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
2020-02-02ppc/pnv: Add models for POWER8 PHB3 PCIe Host bridgeCédric Le Goater1-1/+13
This is a model of the PCIe Host Bridge (PHB3) found on a POWER8 processor. It includes the PowerBus logic interface (PBCQ), IOMMU support, a single PCIe Gen.3 Root Complex, and support for MSI and LSI interrupt sources as found on a POWER8 system using the XICS interrupt controller. The POWER8 processor comes in different flavors: Venice, Murano, Naple, each having a different number of PHBs. To make things simpler, the models provides 3 PHB3 per chip. Some platforms, like the Firestone, can also couple PHBs on the first chip to provide more bandwidth but this is too specific to model in QEMU. XICS requires some adjustment to support the PHB3 MSI. The changes are provided here but they could be decoupled in prereq patches. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20200127144506.11132-3-clg@kaod.org> [dwg: Use device_class_set_props()] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-01-30hw/intc/arm_gicv3_kvm: Stop wrongly programming GICR_PENDBASER.PTZ bitZenghui Yu1-7/+4
If LPIs are disabled, KVM will just ignore the GICR_PENDBASER.PTZ bit when restoring GICR_CTLR. Setting PTZ here makes littlt sense in "reduce GIC initialization time". And what's worse, PTZ is generally programmed by guest to indicate to the Redistributor whether the LPI Pending table is zero when enabling LPIs. If migration is triggered when the PTZ has just been cleared by guest (and before enabling LPIs), we will see PTZ==1 on the destination side, which is not as expected. Let's just drop this hackish userspace behavior. Also take this chance to refine the comment a bit. Fixes: 367b9f527bec ("hw/intc/arm_gicv3_kvm: Implement get/put functions") Signed-off-by: Zenghui Yu <yuzenghui@huawei.com> Message-id: 20200119133051.642-1-yuzenghui@huawei.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-01-30add device_legacy_reset function to prepare for reset api changeDamien Hedde1-1/+1
Provide a temporary device_legacy_reset function doing what device_reset does to prepare for the transition with Resettable API. All occurrence of device_reset in the code tree are also replaced by device_legacy_reset. The new resettable API has different prototype and semantics (resetting child buses as well as the specified device). Subsequent commits will make the changeover for each call site individually; once that is complete device_legacy_reset() will be removed. Signed-off-by: Damien Hedde <damien.hedde@greensocs.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Acked-by: David Gibson <david@gibson.dropbear.id.au> Acked-by: Cornelia Huck <cohuck@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20200123132823.1117486-2-damien.hedde@greensocs.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-01-27s390x: adapter routes error handlingCornelia Huck1-0/+8
If the kernel irqchip has been disabled, we don't want the {add,release}_adapter_routes routines to call any kvm_irqchip_* interfaces, as they may rely on an irqchip actually having been created. Just take a quick exit in that case instead. If you are trying to use irqfd without a kernel irqchip, we will fail with an error. Also initialize routes->gsi[] with -1 in the virtio-ccw handling, to make sure we don't trip over other errors, either. (Nobody else uses the gsi array in that structure.) Fixes: d426d9fba8ea ("s390x/virtio-ccw: wire up irq routing and irqfds") Reviewed-by: Thomas Huth <thuth@redhat.com> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Message-Id: <20200117111147.5006-1-cohuck@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2020-01-27intc/s390_flic_kvm.c: remove unneeded label in kvm_flic_load()Daniel Henrique Barboza1-7/+3
'out' label can be replaced by 'return' with the appropriate value that is set by 'r' right before the jump. Cc: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20200106182425.20312-42-danielhb413@gmail.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2020-01-24qdev: set properties with device_class_set_props()Marc-André Lureau22-28/+28
The following patch will need to handle properties registration during class_init time. Let's use a device_class_set_props() setter. spatch --macro-file scripts/cocci-macro-file.h --sp-file ./scripts/coccinelle/qdev-set-props.cocci --keep-comments --in-place --dir . @@ typedef DeviceClass; DeviceClass *d; expression val; @@ - d->props = val + device_class_set_props(d, val) Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20200110153039.1379601-20-marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-01-20apic: Use 32bit APIC ID for migration instance IDPeter Xu1-1/+4
Migration is silently broken now with x2apic config like this: -smp 200,maxcpus=288,sockets=2,cores=72,threads=2 \ -device intel-iommu,intremap=on,eim=on After migration, the guest kernel could hang at anything, due to x2apic bit not migrated correctly in IA32_APIC_BASE on some vcpus, so any operations related to x2apic could be broken then (e.g., RDMSR on x2apic MSRs could fail because KVM would think that the vcpu hasn't enabled x2apic at all). The issue is that the x2apic bit was never applied correctly for vcpus whose ID > 255 when migrate completes, and that's because when we migrate APIC we use the APICCommonState.id as instance ID of the migration stream, while that's too short for x2apic. Let's use the newly introduced initial_apic_id for that. Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2020-01-20migration: Change SaveStateEntry.instance_id into uint32_tPeter Xu1-1/+1
It was always used as 32bit, so define it as used to be clear. Instead of using -1 as the auto-gen magic value, we switch to UINT32_MAX. We also make sure that we don't auto-gen this value to avoid overflowed instance IDs without being noticed. Suggested-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2020-01-20migration: Define VMSTATE_INSTANCE_ID_ANYPeter Xu1-1/+1
Define the new macro VMSTATE_INSTANCE_ID_ANY for callers who wants to auto-generate the vmstate instance ID. Previously it was hard coded as -1 instead of this macro. It helps to change this default value in the follow up patches. No functional change. Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2020-01-17arm/gicv3: update virtual irq state after IAR register readJeff Kubascik1-0/+3
The IAR0/IAR1 register is used to acknowledge an interrupt - a read of the register activates the highest priority pending interrupt and provides its interrupt ID. Activating an interrupt can change the CPU's virtual interrupt state - this change makes sure the virtual irq state is updated. Signed-off-by: Jeff Kubascik <jeff.kubascik@dornerworks.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20200113154607.97032-1-jeff.kubascik@dornerworks.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-01-10Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into stagingPeter Maydell1-0/+1
* Compat machines fix (Denis) * Command line parsing fixes (Michal, Peter, Xiaoyao) * Cooperlake CPU model fixes (Xiaoyao) * i386 gdb fix (mkdolata) * IOEventHandler cleanup (Philippe) * icount fix (Pavel) * RR support for random number sources (Pavel) * Kconfig fixes (Philippe) # gpg: Signature made Wed 08 Jan 2020 10:41:00 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: (38 commits) chardev: Use QEMUChrEvent enum in IOEventHandler typedef chardev: use QEMUChrEvent instead of int chardev/char: Explicit we ignore some QEMUChrEvent in IOEventHandler monitor/hmp: Explicit we ignore a QEMUChrEvent in IOEventHandler monitor/qmp: Explicit we ignore few QEMUChrEvent in IOEventHandler virtio-console: Explicit we ignore some QEMUChrEvent in IOEventHandler vhost-user-blk: Explicit we ignore few QEMUChrEvent in IOEventHandler vhost-user-net: Explicit we ignore few QEMUChrEvent in IOEventHandler vhost-user-crypto: Explicit we ignore some QEMUChrEvent in IOEventHandler ccid-card-passthru: Explicit we ignore QEMUChrEvent in IOEventHandler hw/usb/redirect: Explicit we ignore few QEMUChrEvent in IOEventHandler hw/usb/dev-serial: Explicit we ignore few QEMUChrEvent in IOEventHandler hw/char/terminal3270: Explicit ignored QEMUChrEvent in IOEventHandler hw/ipmi: Explicit we ignore some QEMUChrEvent in IOEventHandler hw/ipmi: Remove unnecessary declarations target/i386: Add missed features to Cooperlake CPU model target/i386: Add new bit definitions of MSR_IA32_ARCH_CAPABILITIES target/i386: Fix handling of k_gs_base register in 32-bit mode in gdbstub hw/rtc/mc146818: Add missing dependency on ISA Bus hw/nvram/Kconfig: Restrict CHRP NVRAM to machines using OpenBIOS or SLOF ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-01-10Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-5.0-20200108' ↵Peter Maydell4-17/+52
into staging ppc patch queue 2020-01-08 Here's another pull request for qemu-5.0 of ppc related changes. Highlights are: * First parts of support for POWER Secure VMs * Rework to clean up how we pass context information to the various components of the pnv machine (reduces usage of qdev_get_machine()) * Assorted cleanups and bugfixes # gpg: Signature made Wed 08 Jan 2020 05:22:08 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-20200108: (26 commits) ppc/pnv: fix check on return value of blk_getlength() ppc/pnv: check return value of blk_pwrite() pnv/psi: Consolidate some duplicated code in pnv_psi_realize() pnv/psi: Add device reset hook pnv/xive: Deduce the PnvXive pointer from XiveTCTX::xptr spapr/xive: Deduce the SpaprXive pointer from XiveTCTX::xptr xive: Add a "presenter" link property to the TCTX object ppc/pnv: Add a "pnor" const link property to the BMC internal simulator ppc/pnv: Add an "nr-threads" property to the base chip class xive: Use the XIVE fabric link under the XIVE router spapr, pnv, xive: Add a "xive-fabric" link to the XIVE router pnv/xive: Use device_class_set_parent_realize() ppc/pnv: Introduce a "xics" property under the POWER8 chip ppc/pnv: Introduce a "xics" property alias under the PSI model spapr/xive: remove redundant check in spapr_match_nvt() ppc/pnv: Drop "num-chips" machine property ppc440_bamboo.c: remove label from bamboo_load_device_tree() spapr.c: remove 'out' label in spapr_dt_cas_updates() ppc/spapr: Don't call KVM_SVM_OFF ioctl on TCG spapr/xive: Use device_class_set_parent_realize() ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-01-08pnv/xive: Deduce the PnvXive pointer from XiveTCTX::xptrGreg Kurz1-6/+2
And use it instead of reaching out to the machine. This allows to get rid of pnv_get_chip(). Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20200106145645.4539-11-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-01-08spapr/xive: Deduce the SpaprXive pointer from XiveTCTX::xptrGreg Kurz1-5/+4
And use it instead of reaching out to the machine. This allows to get rid of a call to qdev_get_machine() and to reduce the scope of another one so that it is only used within the argument list of error_append_hint(). This is an acceptable tradeoff compared to all it would require to know about the maximum number of CPUs here without calling qdev_get_machine(). Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20200106145645.4539-10-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-01-08xive: Add a "presenter" link property to the TCTX objectCédric Le Goater2-2/+6
This will be used in subsequent patches to access the XIVE associated to a TCTX without reaching out to the machine through qdev_get_machine(). Signed-off-by: Cédric Le Goater <clg@kaod.org> [ groug: - split patch - write subject and changelog ] Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20200106145645.4539-9-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-01-08xive: Use the XIVE fabric link under the XIVE routerGreg Kurz1-3/+11
Now that the spapr and pnv machines do set the "xive-fabric" link, the use of the XIVE fabric pointer becomes mandatory. This is checked with an assert() in a new realize hook. Since the XIVE router is realized at machine init for the all the machine's life time, no risk to abort an already running guest (ie. not a hotplug path). This gets rid of a qdev_get_machine() call. Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20200106145645.4539-6-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-01-08spapr, pnv, xive: Add a "xive-fabric" link to the XIVE routerGreg Kurz1-0/+8
In order to get rid of qdev_get_machine(), first add a pointer to the XIVE fabric under the XIVE router and make it configurable through a QOM link property. Configure it in the spapr and pnv machine. In the case of pnv, the XIVE routers are under the chip, so this is done with a QOM alias property of the POWER9 pnv chip. Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20200106145645.4539-5-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-01-08pnv/xive: Use device_class_set_parent_realize()Greg Kurz1-0/+10
The XIVE router base class currently inherits an empty realize hook from the sysbus device base class, but it will soon implement one of its own to perform some sanity checks. Do the preliminary plumbing to have it called. Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20200106145645.4539-4-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-01-08spapr/xive: Use device_class_set_parent_realize()Greg Kurz1-1/+11
The XIVE router base class currently inherits an empty realize hook from the sysbus device base class, but it will soon implement one of its own to perform some sanity checks. Do the preliminary plumbing to have it called. Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191219181155.32530-6-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-01-07omap-intc: remove PROP_PTRMarc-André Lureau1-7/+10
Since clocks are not QOM objects, replace PROP_PTR of clocks with setters methods. (in theory there should probably be different methods for omap1 & omap2 intc, but this is left as a future improvement) Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2020-01-07cris: improve passing PIC interrupt vector to the CPUMarc-André Lureau1-25/+1
Instead of accessing cpu interrupt vector directly from PIC, send the vector value over the qemu_irq. Suggested-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2020-01-07leon3: use qemu_irq framework instead of callback as propertyMarc-André Lureau1-31/+4
"set_pin_in" property is used to define a callback mechanism where the device says "call the callback function, passing it an opaque cookie and a 32-bit value". We already have a generic mechanism for doing that, which is the qemu_irq. So we should just use that. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: KONRAD Frederic <frederic.konrad@adacore.com>
2020-01-07hw/intc/i8259: Fix Kconfig dependency on ISA busPhilippe Mathieu-Daudé1-0/+1
The 8259 Interrupt Controller sits on a ISA bus. Add the missing dependency to fix: LINK x86_64-softmmu/qemu-system-x86_64 /usr/bin/ld: ../hw/intc/i8259_common.o: in function `pic_common_realize': hw/intc/i8259_common.c:84: undefined reference to `isa_register_ioport' /usr/bin/ld: hw/intc/i8259_common.c:86: undefined reference to `isa_register_ioport' /usr/bin/ld: ../hw/intc/i8259_common.o: in function `i8259_init_chip': hw/intc/i8259_common.c:97: undefined reference to `isa_create' collect2: error: ld returned 1 exit status make[1]: *** [Makefile:206: qemu-system-x86_64] Error 1 Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20191231183216.6781-3-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-12-20Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into stagingPeter Maydell5-4/+7
* More uses of RCU_READ_LOCK_GUARD (Dave, myself) * QOM doc improvments (Greg) * Cleanups from the Meson conversion (Marc-André) * Support for multiple -accel options (myself) * Many x86 machine cleanup (Philippe, myself) * tests/migration-test cleanup (Juan) * PC machine removal and next round of deprecation (Thomas) * kernel-doc integration (Peter, myself) # gpg: Signature made Wed 18 Dec 2019 01:35:02 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: (87 commits) vga: cleanup mapping of VRAM for non-PCI VGA hw/display: Remove "rombar" hack from vga-pci and vmware_vga hw/pci: Remove the "command_serr_enable" property hw/audio: Remove the "use_broken_id" hack from the AC97 device hw/i386: Remove the deprecated machines 0.12 up to 0.15 hw/pci-host: Add Kconfig entry to select the IGD Passthrough Host Bridge hw/pci-host/i440fx: Extract the IGD passthrough host bridge device hw/pci-host/i440fx: Use definitions instead of magic values hw/pci-host/i440fx: Use size_t to iterate over ARRAY_SIZE() hw/pci-host/i440fx: Extract PCII440FXState to "hw/pci-host/i440fx.h" hw/pci-host/i440fx: Correct the header description Fix some comment spelling errors. target/i386: remove unused pci-assign codes WHPX: refactor load library migration: check length directly to make sure the range is aligned memory: include MemoryListener documentation and some missing function parameters docs: add memory API reference memory.h: Silence kernel-doc complaints docs: Create bitops.rst as example of kernel-docs bitops.h: Silence kernel-doc complaints ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-12-18hw/intc/s390: Simplify error handling in kvm_s390_flic_realize()Markus Armbruster1-6/+4
Cc: Halil Pasic <pasic@linux.ibm.com> Cc: Cornelia Huck <cohuck@redhat.com> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Acked-by: Halil Pasic <pasic@linux.ibm.com> Message-Id: <20191204093625.14836-18-armbru@redhat.com>
2019-12-18error: Clean up unusual names of Error * variablesMarkus Armbruster1-5/+5
Local Error * variables are conventionally named @err or @local_err, and Error ** parameters @errp. Naming local variables like parameters is confusing. Clean that up. Naming parameters like local variables is also confusing. Left for another day. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20191204093625.14836-17-armbru@redhat.com>
2019-12-17hw: replace hw/i386/pc.h with a header just for the i8259Paolo Bonzini5-4/+7
Remove the need to include i386/pc.h to get to the i8259 functions. This is enough to remove the inclusion of hw/i386/pc.h from all non-x86 files. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-12-17xics: Don't deassert outputsGreg Kurz1-3/+0
The correct way to do this is to deassert the input pins on the CPU side. This is the case since a previous change. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <157548862298.3650476.1228720391270249433.stgit@bahia.lan> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-12-17ppc/pnv: Dump the XIVE NVT tableCédric Le Goater1-0/+64
This is useful to dump the saved contexts of the vCPUs : configuration of the base END index of the vCPU and the Interrupt Pending Buffer register, which is updated when an interrupt can not be presented. When dumping the NVT table, we skip empty indirect pages which are not necessarily allocated. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191125065820.927-21-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-12-17ppc/pnv: Extend XiveRouter with a get_block_id() handlerCédric Le Goater3-5/+28
When doing CAM line compares, fetch the block id from the interrupt controller which can have set the PC_TCTXT_CHIPID field. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191125065820.927-20-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-12-17ppc/pnv: Introduce a pnv_xive_block_id() helperCédric Le Goater1-31/+33
When PC_TCTXT_CHIPID_OVERRIDE is configured, the PC_TCTXT_CHIPID field overrides the hardwired chip ID in the Powerbus operations and for CAM compares. This is typically used in the one block-per-chip configuration to associate a unique block id number to each IC of the system. Simplify the model with a pnv_xive_block_id() helper and remove 'tctx_chipid' which becomes useless. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191125065820.927-19-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-12-17ppc/xive: Synthesize interrupt from the saved IPB in the NVTCédric Le Goater1-0/+52
When a vCPU is dispatched on a HW thread, its context is pushed in the thread registers and it is activated by setting the VO bit in the CAM line word2. The HW grabs the associated NVT, pulls the IPB bits and merges them with the IPB of the new context. If interrupts were missed while the vCPU was not dispatched, these are synthesized in this sequence. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191125065820.927-18-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-12-17ppc/xive: Introduce a xive_tctx_ipb_update() helperCédric Le Goater1-10/+11
We will use it to resend missed interrupts when a vCPU context is pushed on a HW thread. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191125065820.927-17-clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-12-17ppc/xive: Remove the get_tctx() XiveRouter handlerCédric Le Goater3-28/+0
It is now unused. Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191125065820.927-16-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-12-17ppc/xive: Move the TIMA operations to the controller modelCédric Le Goater3-32/+65
On the P9 Processor, the thread interrupt context registers of a CPU can be accessed "directly" when by load/store from the CPU or "indirectly" by the IC through an indirect TIMA page. This requires to configure first the PC_TCTXT_INDIRx registers. Today, we rely on the get_tctx() handler to deduce from the CPU PIR the chip from which the TIMA access is being done. By handling the TIMA memory ops under the interrupt controller model of each machine, we can uniformize the TIMA direct and indirect ops under PowerNV. We can also check that the CPUs have been enabled in the XIVE controller. This prepares ground for the future versions of XIVE. Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191125065820.927-15-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-12-17ppc/pnv: Clarify how the TIMA is accessed on a multichip systemCédric Le Goater1-17/+23
The TIMA region gives access to the thread interrupt context registers of a CPU. It is mapped at the same address on all chips and can be accessed by any CPU of the system. To identify the chip from which the access is being done, the PowerBUS uses a 'chip' field in the load/store messages. QEMU does not model these messages, instead, we extract the chip id from the CPU PIR and do a lookup at the machine level to fetch the targeted interrupt controller. Introduce pnv_get_chip() and pnv_xive_tm_get_xive() helpers to clarify this process in pnv_xive_get_tctx(). The latter will be removed in the subsequent patches but the same principle will be kept. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191125065820.927-14-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-12-17spapr/xive: Configure number of servers in KVMGreg Kurz1-2/+21
The XIVE KVM devices now has an attribute to configure the number of interrupt servers. This allows to greatly optimize the usage of the VP space in the XIVE HW, and thus to start a lot more VMs. Only set this attribute if available in order to support older POWER9 KVM. The XIVE KVM device now reports the exhaustion of VPs upon the connection of the first VCPU. Check that in order to have a chance to provide a hint to the user. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <157478679392.67101.7843580591407950866.stgit@bahia.tlslab.ibm.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-12-17spapr/xics: Configure number of servers in KVMGreg Kurz1-2/+19
The XICS-on-XIVE KVM devices now has an attribute to configure the number of interrupt servers. This allows to greatly optimize the usage of the VP space in the XIVE HW, and thus to start a lot more VMs. Only set this attribute if available in order to support older POWER9 KVM and pre-POWER9 XICS KVM devices. The XICS-on-XIVE KVM device now reports the exhaustion of VPs upon the connection of the first VCPU. Check that in order to have a chance to provide a hint to the user. ` Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <157478678846.67101.9660531022460517710.stgit@bahia.tlslab.ibm.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-12-17spapr: Pass the maximum number of vCPUs to the KVM interrupt controllerGreg Kurz4-6/+11
The XIVE and XICS-on-XIVE KVM devices on POWER9 hosts can greatly reduce their consumption of some scarce HW resources, namely Virtual Presenter identifiers, if they know the maximum number of vCPUs that may run in the VM. Prepare ground for this by passing the value down to xics_kvm_connect() and kvmppc_xive_connect(). This is purely mechanical, no functional change. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <157478678301.67101.2717368060417156338.stgit@bahia.tlslab.ibm.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
generated by cgit v1.1 at 2024-12-28 19:17:28 +0000