summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* libqos: add iteration support to qpci_find_capability()Stefan Hajnoczi2019-10-252-7/+25
| | | | | | | | | | | | | | | VIRTIO 1.0 PCI devices have multiple PCI_CAP_ID_VNDR capabilities so we need a way to iterate over them. Extend qpci_find_capability() to take the last address. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> -- v3: * Document qpci_find_capability() Message-Id: <20191023100425.12168-11-stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* libqos: access VIRTIO 1.0 vring in little-endianStefan Hajnoczi2019-10-255-39/+106
| | | | | | | | | | | | | | VIRTIO 1.0 uses little-endian for the vring. Legacy VIRTIO uses guest endianness. Adjust the code to handle both. Note that qvirtio_readq() is not defined because it has no users. All the other accessors are really needed. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20191023100425.12168-10-stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* libqos: implement VIRTIO 1.0 FEATURES_OK stepStefan Hajnoczi2019-10-251-1/+17
| | | | | | | | | | | | | | | | | | | | Device initialization has an extra step in VIRTIO 1.0. The FEATURES_OK status bit is set to indicate that feature negotiation has completed. The driver then reads the status register again to check that the device agrees with the final features. Implement this step as part of qvirtio_set_features() instead of introducing a separate function. This way all existing code works without modifications. The check in qvirtio_set_driver_ok() needs to be updated because FEATURES_OK will be set for VIRTIO 1.0 devices. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20191023100425.12168-9-stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Thomas Huth" <thuth@redhat.com>
* libqos: enforce Device Initialization orderStefan Hajnoczi2019-10-252-0/+8
| | | | | | | | | | | | According to VIRTIO 1.1 "3.1.1 Driver Requirements: Device Initialization", configuration space and virtqueues cannot be accessed before features have been negotiated. Enforce this requirement. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20191023100425.12168-8-stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com>
* libqos: add missing virtio-9p feature negotiationStefan Hajnoczi2019-10-251-0/+6
| | | | | | | | | | | | | | | | | VIRTIO Device Initialization requires feature negotiation. The libqos virtio-9p driver lacks feature negotiation and is therefore non-compliant. libqos tests acknowledge all feature bits advertised by the device, except VIRTIO_F_BAD_FEATURE (which devices use to detect broken drivers!) and VIRTIO_RING_F_EVENT_IDX (which is not implemented in libqos and accepting it would break notifications). Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20191023100425.12168-7-stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Thomas Huth" <thuth@redhat.com>
* tests/virtio-blk-test: set up virtqueue after feature negotiationStefan Hajnoczi2019-10-251-7/+10
| | | | | | | | | | | | | VIRTIO Device Initialization requires that feature negotiation has completed before virtqueues are set up. This makes sense because the driver must know whether it is operating in Legacy or VIRTIO 1.0 mode before it can access vring fields with the correct endianness. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20191023100425.12168-6-stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* virtio-scsi-test: add missing feature negotiationStefan Hajnoczi2019-10-251-0/+8
| | | | | | | | | | | | | | | | VIRTIO Device Initialization requires feature negotiation. Currently virtio-scsi-test.c is non-compliant. libqos tests acknowledge all feature bits advertised by the device, except VIRTIO_F_BAD_FEATURE (which devices use to detect broken drivers!) and VIRTIO_RING_F_EVENT_IDX (which is not implemented in libqos and accepting it would break notifications). Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20191023100425.12168-5-stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Thomas Huth" <thuth@redhat.com>
* libqos: extend feature bits to 64-bitStefan Hajnoczi2019-10-256-27/+43
| | | | | | | | | | | | | | | | In VIRTIO 1.0 feature bits changed from 32-bit to 64-bit. (In fact, the transports allow even more feature bits but nothing uses more than 64 bits today.) Add 64-bit feature bit support to virtio-mmio and virtio-pci. This will be necessary for VIRTIO 1.0 support. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20191023100425.12168-4-stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* libqos: read QVIRTIO_MMIO_VERSION registerStefan Hajnoczi2019-10-252-0/+4
| | | | | | | | | | | | | | | | | | | | There was no real virtio-mmio ABI change between Legacy and VIRTIO 1.0 except that the Version field was incremented from 1 to 2. However, QEMU does not allow Legacy drivers to perform VIRTIO 1.0 operations like accessing 64-bit feature bits. Since we will introduce 64-bit feature bit support we need a way to differentiate between virtio-mmio Version 1 and 2 to avoid upsetting QEMU when we operate in Legacy mode. Stash away the Version field so later patches can change behavior depending on the version. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20191023100425.12168-3-stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* tests/virtio-blk-test: read config space after feature negotiationStefan Hajnoczi2019-10-251-13/+20
| | | | | | | | | | | | | | The VIRTIO Configuration Space cannot be accessed before device feature bits have been read because a driver doesn't know the endianness until it has checked VIRTIO_F_VERSION_1. Fix this problem in preparation for VIRTIO 1.0 support. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20191023100425.12168-2-stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* virtio: add property to enable packed virtqueueJason Wang2019-10-251-1/+3
| | | | | | | | | Signed-off-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Reviewed-by: Jens Freimann <jfreimann@redhat.com> Message-Id: <20191025083527.30803-9-eperezma@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* vhost_net: enable packed ring supportJason Wang2019-10-251-0/+2
| | | | | | | | | Signed-off-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Reviewed-by: Jens Freimann <jfreimann@redhat.com> Message-Id: <20191025083527.30803-8-eperezma@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* virtio: event suppression support for packed ringJason Wang2019-10-251-9/+133
| | | | | | | | | | | | This patch implements event suppression through device/driver area. Please refer virtio specification for more information. Signed-off-by: Wei Xu <wexu@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Message-Id: <20191025083527.30803-7-eperezma@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* virtio: basic packed virtqueue supportJason Wang2019-10-255-75/+829
| | | | | | | | | | | | | | | | This patch implements basic support for the packed virtqueue. Compare the split virtqueue which has three rings, packed virtqueue only have one which is supposed to have better cache utilization and more hardware friendly. Please refer virtio specification for more information. Signed-off-by: Wei Xu <wexu@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Message-Id: <20191025083527.30803-6-eperezma@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* virtio: Free rnd virqueue at unrealize()Eugenio Pérez2019-10-251-0/+1
| | | | | | | | | | | | | The function virtio_del_queue was not called at unrealize() callback. This was detected due to add an allocated element on the vq introduce in future commits (used_elems) and running address sanitizer memory leak detector. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Message-Id: <20191025083527.30803-5-eperezma@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* virtio: Free blk virqueues at unrealize()Eugenio Pérez2019-10-251-0/+5
| | | | | | | | | | | | | The function virtio_del_queue was not called at unrealize() callback. This was detected due to add an allocated element on the vq introduce in future commits (used_elems) and running address sanitizer memory leak detector. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Message-Id: <20191025083527.30803-4-eperezma@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* virtio: device/driver area size calculation refactor for split ringWei Xu2019-10-251-6/+10
| | | | | | | | | | | | | | | There is slight size difference between split/packed rings. This is the refactor of split ring as well as a helper to expanding device and driver area size calculation for packed ring. Signed-off-by: Wei Xu <wexu@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Reviewed-by: Jens Freimann <jfreimann@redhat.com> Message-Id: <20191025083527.30803-3-eperezma@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* virtio: basic structure for packed ringWei Xu2019-10-251-0/+15
| | | | | | | | | | | | | Define packed ring structure according to Qemu nomenclature, field data(wrap counter, etc) are also included. Signed-off-by: Wei Xu <wexu@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Reviewed-by: Jens Freimann <jfreimann@redhat.com> Message-Id: <20191025083527.30803-2-eperezma@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-4.2-20191024' ↵Peter Maydell2019-10-2428-666/+839
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | into staging ppc patch queue 2019-10-24 Last pull request before soft freeze. * Lots of fixes and cleanups for spapr interrupt controllers * More SLOF updates to fix problems with full FDT rendering at CAS time (alas, more yet are to come) * A few other assorted changes This isn't quite as well tested as I usually try to do before a pull request. But I've been sick and running into some other difficulties, and wanted to get this sent out before heading towards KVM forum. # gpg: Signature made Thu 24 Oct 2019 09:14:31 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.2-20191024: (28 commits) spapr/xive: Set the OS CAM line at reset ppc/pnv: Fix naming of routines realizing the CPUs ppc: Reset the interrupt presenter from the CPU reset handler ppc/pnv: Add a PnvChip pointer to PnvCore ppc/pnv: Introduce a PnvCore reset handler spapr_cpu_core: Implement DeviceClass::reset spapr: move CPU reset after presenter creation spapr: Don't request to unplug the same core twice pseries: Update SLOF firmware image spapr: Move SpaprIrq::nr_xirqs to SpaprMachineClass spapr: Remove SpaprIrq::nr_msis spapr, xics, xive: Move SpaprIrq::post_load hook to backends spapr, xics, xive: Move SpaprIrq::reset hook logic into activate/deactivate spapr: Remove SpaprIrq::init_kvm hook spapr, xics, xive: Match signatures for XICS and XIVE KVM connect routines spapr, xics, xive: Move dt_populate from SpaprIrq to SpaprInterruptController spapr, xics, xive: Move print_info from SpaprIrq to SpaprInterruptController spapr, xics, xive: Move set_irq from SpaprIrq to SpaprInterruptController spapr: Formalize notion of active interrupt controller spapr, xics, xive: Move irq claim and free from SpaprIrq to SpaprInterruptController ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
| * spapr/xive: Set the OS CAM line at resetCédric Le Goater2019-10-242-32/+17Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a Virtual Processor is scheduled to run on a HW thread, the hypervisor pushes its identifier in the OS CAM line. When running with kernel_irqchip=off, QEMU needs to emulate the same behavior. Set the OS CAM line when the interrupt presenter of the sPAPR core is reset. This will also cover the case of hot-plugged CPUs. This change also has the benefit to remove the use of CPU_FOREACH() which can be unsafe. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org> Message-Id: <20191022163812.330-8-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
| * ppc/pnv: Fix naming of routines realizing the CPUsCédric Le Goater2019-10-241-4/+4
| | | | | | | | | | | | | | | | | | | | | | The 'vcpu' suffix is inherited from the sPAPR machine. Use better names for PowerNV. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org> Message-Id: <20191022163812.330-7-clg@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
| * ppc: Reset the interrupt presenter from the CPU reset handlerCédric Le Goater2019-10-2412-20/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On the sPAPR machine and PowerNV machine, the interrupt presenters are created by a machine handler at the core level and are reset independently. This is not consistent and it raises issues when it comes to handle hot-plugged CPUs. In that case, the presenters are not reset. This is less of an issue in XICS, although a zero MFFR could be a concern, but in XIVE, the OS CAM line is not set and this breaks the presenting algorithm. The current code has workarounds which need a global cleanup. Extend the sPAPR IRQ backend and the PowerNV Chip class with a new cpu_intc_reset() handler called by the CPU reset handler and remove the XiveTCTX reset handler which is now redundant. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191022163812.330-6-clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
| * ppc/pnv: Add a PnvChip pointer to PnvCoreCédric Le Goater2019-10-242-1/+5
| | | | | | | | | | | | | | | | | | | | | | We will use it to reset the interrupt presenter from the CPU reset handler. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org> Message-Id: <20191022163812.330-5-clg@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
| * ppc/pnv: Introduce a PnvCore reset handlerCédric Le Goater2019-10-241-4/+15
| | | | | | | | | | | | | | | | | | | | | | in which individual CPUs are reset. It will ease the introduction of future change reseting the interrupt presenter from the CPU reset handler. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org> Message-Id: <20191022163812.330-4-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
| * spapr_cpu_core: Implement DeviceClass::resetGreg Kurz2019-10-241-9/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since vCPUs aren't plugged into a bus, we manually register a reset handler for each vCPU. We also call this handler at realize time to ensure hot plugged vCPUs are reset before being exposed to the guest. This results in vCPUs being reset twice at machine reset. It doesn't break anything but it is slightly suboptimal and above all confusing. The hotplug path in device_set_realized() already knows how to reset a hotplugged device if the device reset handler is present. Implement one for sPAPR CPU cores that resets all vCPUs under a core. While here rename spapr_cpu_reset() to spapr_reset_vcpu() for consistency with spapr_realize_vcpu() and spapr_unrealize_vcpu(). Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> [clg: add documentation on the reset helper usage ] Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191022163812.330-3-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
| * spapr: move CPU reset after presenter creationCédric Le Goater2019-10-241-6/+8
| | | | | | | | | | | | | | | | | | | | | | | | This change prepares ground for future changes which will reset the interrupt presenter in the reset handler of the sPAPR and PowerNV cores. Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191022163812.330-2-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
| * spapr: Don't request to unplug the same core twiceGreg Kurz2019-10-241-3/+4
| | | | | | | | | | | | | | | | | | | | We must not call spapr_drc_detach() on a detached DRC otherwise bad things can happen, ie. QEMU hangs or crashes. This is easily demonstrated with a CPU hotplug/unplug loop using QMP. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <157185826035.3073024.1664101000438499392.stgit@bahia.lan> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
| * pseries: Update SLOF firmware imageAlexey Kardashevskiy2019-10-243-1/+1
| | | | | | | | | | | | | | | | | | This aims v4.2 and fixes: 1. full FDT rendering; 2. gcc9 -Waddress-of-packed-member. Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
| * spapr: Move SpaprIrq::nr_xirqs to SpaprMachineClassDavid Gibson2019-10-244-18/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For the benefit of peripheral device allocation, the number of available irqs really wants to be the same on a given machine type version, regardless of what irq backends we are using. That's the case now, but only because we make sure the different SpaprIrq instances have the same value except for the special legacy one. Since this really only depends on machine type version, move the value to SpaprMachineClass instead of SpaprIrq. This also puts the code to set it to the lower value on old machine types right next to setting legacy_irq_allocation, which needs to go hand in hand. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org>
| * spapr: Remove SpaprIrq::nr_msisDavid Gibson2019-10-245-20/+26
| | | | | | | | | | | | | | | | | | | | | | The nr_msis value we use here has to line up with whether we're using legacy or modern irq allocation. Therefore it's safer to derive it based on legacy_irq_allocation rather than having SpaprIrq contain a canned value. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org>
| * spapr, xics, xive: Move SpaprIrq::post_load hook to backendsDavid Gibson2019-10-245-46/+21Star
| | | | | | | | | | | | | | | | | | | | | | The remaining logic in the post_load hook really belongs to the interrupt controller backends, and just needs to be called on the active controller (after the active controller is set to the right thing based on the incoming migration in the generic spapr_irq_post_load() logic). Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org>
| * spapr, xics, xive: Move SpaprIrq::reset hook logic into activate/deactivateDavid Gibson2019-10-244-65/+61Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It turns out that all the logic in the SpaprIrq::reset hooks (and some in the SpaprIrq::post_load hooks) isn't really related to resetting the irq backend (that's handled by the backends' own reset routines). Rather its about getting the backend ready to be the active interrupt controller or stopping being the active interrupt controller - reset (and post_load) is just the only time that changes at present. To make this flow clearer, move the logic into the explicit backend activate and deactivate hooks. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org>
| * spapr: Remove SpaprIrq::init_kvm hookDavid Gibson2019-10-242-50/+25Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This hook is a bit odd. The only caller is spapr_irq_init_kvm(), but it explicitly takes an SpaprIrq *, so it's never really called through the current SpaprIrq. Essentially this is just a way of passing through a function pointer so that spapr_irq_init_kvm() can handle some configuration and error handling logic without duplicating it between the xics and xive reset paths. So, make it just take that function pointer. Because of earlier reworks to the KVM connect/disconnect code in the xics and xive backends we can also eliminate some wrapper functions and streamline error handling a bit. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org>
| * spapr, xics, xive: Match signatures for XICS and XIVE KVM connect routinesDavid Gibson2019-10-245-37/+24Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Both XICS and XIVE have routines to connect and disconnect KVM with similar but not identical signatures. This adjusts them to match exactly, which will be useful for further cleanups later. While we're there, we add an explicit return value to the connect path to streamline error reporting in the callers. We remove error reporting the disconnect path. In the XICS case this wasn't used at all. In the XIVE case the only error case was if the KVM device was set up, but KVM didn't have the capability to do so which is pretty obviously impossible. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org>
| * spapr, xics, xive: Move dt_populate from SpaprIrq to SpaprInterruptControllerDavid Gibson2019-10-247-83/+80Star
| | | | | | | | | | | | | | | | | | | | | | This method depends only on the active irq controller. Now that we've formalized the notion of active controller we can dispatch directly through that, rather than dispatching via SpaprIrq with the dual version having to do a second conditional dispatch. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org>
| * spapr, xics, xive: Move print_info from SpaprIrq to SpaprInterruptControllerDavid Gibson2019-10-245-39/+41
| | | | | | | | | | | | | | | | | | | | | | This method depends only on the active irq controller. Now that we've formalized the notion of active controller we can dispatch directly through that, rather than dispatching via SpaprIrq with the dual version having to do a second conditional dispatch. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org>
| * spapr, xics, xive: Move set_irq from SpaprIrq to SpaprInterruptControllerDavid Gibson2019-10-244-32/+34
| | | | | | | | | | | | | | | | | | | | | | This method depends only on the active irq controller. Now that we've formalized the notion of active controller we can dispatch directly through that, rather than dispatching via SpaprIrq with the dual version having to do a second conditional dispatch. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org>
| * spapr: Formalize notion of active interrupt controllerDavid Gibson2019-10-243-2/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | spapr now has the mechanism of constructing both XICS and XIVE instances of the SpaprInterruptController interface. However, only one of the interrupt controllers will actually be active at any given time, depending on feature negotiation with the guest. This is handled in the current code via spapr_irq_current() which checks the OV5 vector from feature negotiation to determine the current backend. Determining the active controller at the point we need it like this can be pretty confusing, because it makes it very non obvious at what points the active controller can change. This can make it difficult to reason about the code and where a change of active controller could appear in sequence with other events. Make this mechanism more explicit by adding an 'active_intc' pointer and an explicit spapr_irq_update_active_intc() function to update it from the CAS state. We also add hooks on the intc backend which will get called when it is activated or deactivated. For now we just introduce the switch and hooks, later patches will actually start using them. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org>
| * spapr, xics, xive: Move irq claim and free from SpaprIrq to ↵David Gibson2019-10-245-115/+102Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | SpaprInterruptController These methods, like cpu_intc_create, really belong to the interrupt controller, but need to be called on all possible intcs. Like cpu_intc_create, therefore, make them methods on the intc and always call it for all existing intcs. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org>
| * spapr, xics, xive: Move cpu_intc_create from SpaprIrq to ↵David Gibson2019-10-245-61/+79
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SpaprInterruptController This method essentially represents code which belongs to the interrupt controller, but needs to be called on all possible intcs, rather than just the currently active one. The "dual" version therefore calls into the xics and xive versions confusingly. Handle this more directly, by making it instead a method on the intc backend, and always calling it on every backend that exists. While we're there, streamline the error reporting a bit. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org>
| * spapr, xics, xive: Introduce SpaprInterruptController QOM interfaceDavid Gibson2019-10-244-0/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The SpaprIrq structure is used to represent ths spapr machine's irq backend. Except that it kind of conflates two concepts: one is the backend proper - a specific interrupt controller that we might or might not be using, the other is the irq configuration which covers the layout of irq space and which interrupt controllers are allowed. This leads to some pretty confusing code paths for the "dual" configuration where its hooks redirect to other SpaprIrq structures depending on the currently active irq controller. To clean this up, we start by introducing a new SpaprInterruptController QOM interface to represent strictly an interrupt controller backend, not counting anything configuration related. We implement this interface in the XICs and XIVE interrupt controllers, and in future we'll move relevant methods from SpaprIrq into it. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org>
| * spapr: Set VSMT to smp_threads by defaultGreg Kurz2019-10-242-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Support for setting VSMT is available in KVM since linux-4.13. Most distros that support KVM on POWER already have it. It thus seem reasonable enough to have the default machine to set VSMT to smp_threads. This brings contiguous VCPU ids and thus brings their upper bound down to the machine's max_cpus. This is especially useful for XIVE KVM devices, which may thus allocate only one VP descriptor per VCPU. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <157010411885.246126.12610015369068227139.stgit@bahia.lan> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
| * ppc/pnv: Use address_space_stq_be() when triggering an interrupt from PSICédric Le Goater2019-10-241-3/+12
| | | | | | | | | | | | | | | | | | | | Include the XIVE_TRIGGER_PQ bit in the trigger data which is how hardware signals to the IC that the PQ bits of the interrupt source have been checked. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191007084102.29776-3-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
| * ppc/pnv: Improve trigger data definitionCédric Le Goater2019-10-243-9/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The trigger data is used for both triggers of a HW source interrupts, PHB, PSI, and triggers for rerouting interrupts between interrupt controllers. When an interrupt is rerouted, the trigger data follows an "END trigger" format. In that case, the remote IC needs EAS containing an END index to perform a lookup of an END. An END trigger, bit0 of word0 set to '1', is defined as : |0123|4567|0123|4567|0123|4567|0123|4567| W0 E=1 |1P--|BLOC| END IDX | W1 E=1 |M | END DATA | An EAS is defined as : |0123|4567|0123|4567|0123|4567|0123|4567| W0 |V---|BLOC| END IDX | W1 |M | END DATA | The END trigger adds an extra 'PQ' bit, bit1 of word0 set to '1', signaling that the PQ bits have been checked. That bit is unused in the initial EAS definition. When a HW device performs the trigger, the trigger data follows an "EAS trigger" format because the trigger data in that case contains an EAS index which the IC needs to look for. An EAS trigger, bit0 of word0 set to '0', is defined as : |0123|4567|0123|4567|0123|4567|0123|4567| W0 E=0 |0P--|---- ---- ---- ---- ---- ---- ----| W1 E=0 |BLOC| EAS INDEX | There is also a 'PQ' bit, bit1 of word0 to '1', signaling that the PQ bits have been checked. Introduce these new trigger bits and rename the XIVE_SRCNO macros in XIVE_EAS to reflect better the nature of the data. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191007084102.29776-2-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
| * target/ppc: Fix for optimized vsl/vsr instructionsStefan Brankovic2019-10-241-44/+40Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In previous implementation, invocation of TCG shift function could request shift of TCG variable by 64 bits when variable 'sh' is 0, which is not supported in TCG (values can be shifted by 0 to 63 bits). This patch fixes this by using two separate invocation of TCG shift functions, with maximum shift amount of 32. Name of variable 'shifted' is changed to 'carry' so variable naming is similar to old helper implementation. Variables 'avrA' and 'avrB' are replaced with variable 'avr'. Fixes: 4e6d0920e7547e6af4bbac5ffe9adfe6ea621822 Reported-by: "Paul A. Clark" <pc@us.ibm.com> Reported-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Suggested-by: Aleksandar Markovic <aleksandar.markovic@rt-rk.com> Signed-off-by: Stefan Brankovic <stefan.brankovic@rt-rk.com> Message-Id: <1570196639-7025-2-git-send-email-stefan.brankovic@rt-rk.com> Tested-by: Paul A. Clarke <pc@us.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
| * xics: Make some device types not user creatableGreg Kurz2019-10-241-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some device types of the XICS model are exposed to the QEMU command line: $ ppc64-softmmu/qemu-system-ppc64 -device help | grep ic[sp] name "icp" name "ics" name "ics-spapr" name "pnv-icp", desc "PowerNV ICP" These are internal devices that shouldn't be instantiable by the user. By the way, they can't be because their respective realize functions expect link properties that can't be set from the command line: qemu-system-ppc64: -device icp: required link 'xics' not found: Property '.xics' not found qemu-system-ppc64: -device ics: required link 'xics' not found: Property '.xics' not found qemu-system-ppc64: -device ics-spapr: required link 'xics' not found: Property '.xics' not found qemu-system-ppc64: -device pnv-icp: required link 'xics' not found: Property '.xics' not found Hide them by setting dc->user_creatable to false in the base class "icp" and "ics" init functions. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <157017826724.337875.14822177178282524024.stgit@bahia.lan> Message-Id: <157045578962.865784.8551555523533955113.stgit@bahia.lan> [dwg: Folded reason comment into base patch] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
| * xive: Make some device types not user creatableGreg Kurz2019-10-241-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some device types of the XIVE model are exposed to the QEMU command line: $ ppc64-softmmu/qemu-system-ppc64 -device help | grep xive name "xive-end-source", desc "XIVE END Source" name "xive-source", desc "XIVE Interrupt Source" name "xive-tctx", desc "XIVE Interrupt Thread Context" These are internal devices that shouldn't be instantiable by the user. By the way, they can't be because their respective realize functions expect link properties that can't be set from the command line: qemu-system-ppc64: -device xive-source: required link 'xive' not found: Property '.xive' not found qemu-system-ppc64: -device xive-end-source: required link 'xive' not found: Property '.xive' not found qemu-system-ppc64: -device xive-tctx: required link 'cpu' not found: Property '.cpu' not found Hide them by setting dc->user_creatable to false in their respective class init functions. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <157017473006.331610.2983143972519884544.stgit@bahia.lan> Message-Id: <157045578401.865784.6058183726552779559.stgit@bahia.lan> Reviewed-by: Cédric Le Goater <clg@kaod.org> [dwg: Folded comment update into base patch] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* | Merge remote-tracking branch ↵Peter Maydell2019-10-244-20/+72
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 'remotes/ehabkost/tags/machine-next-pull-request' into staging x86 and machine queue, 2019-10-23 Features: * Denverton CPU model (Tao Xu) Cleanups: * Eliminate remaining places that abuse memory_region_allocate_system_memory() (Igor Mammedov) # gpg: Signature made Thu 24 Oct 2019 03:45:34 BST # 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/machine-next-pull-request: hppa: drop usage of memory_region_allocate_system_memory() for ROM ppc: rs6000_mc: drop usage of memory_region_allocate_system_memory() sparc64: use memory_region_allocate_system_memory() only for '-m' specified RAM target/i386: Introduce Denverton CPU model Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
| * | hppa: drop usage of memory_region_allocate_system_memory() for ROMIgor Mammedov2019-10-241-3/+2Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | machine_hppa_init() violates memory_region_allocate_system_memory() contract by calling it multiple times which could break with -mem-path. Replace the second usage (for 'rom') with memory_region_init_ram() instead. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20191008113318.7012-4-imammedo@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
| * | ppc: rs6000_mc: drop usage of memory_region_allocate_system_memory()Igor Mammedov2019-10-241-5/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | rs6000mc_realize() violates memory_region_allocate_system_memory() contract by calling it multiple times which could break -mem-path. Replace it with plain memory_region_init_ram() instead. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20191008113318.7012-3-imammedo@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2025-02-01 20:31:28 +0100