qemu.git
3 years agordma: check num_sge does not exceed MAX_SGE
Prasad J Pandit [Wed, 12 Dec 2018 19:30:34 +0000 (01:00 +0530)] 
rdma: check num_sge does not exceed MAX_SGE

rdma back-end has scatter/gather array ibv_sge[MAX_SGE=4] set
to have 4 elements. A guest could send a 'PvrdmaSqWqe' ring element
with 'num_sge' set to > MAX_SGE, which may lead to OOB access issue.
Add check to avoid it.

Reported-by: Saar Amar <saaramar5@gmail.com>
Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
Reviewed-by: Yuval Shaia <yuval.shaia@oracle.com>
Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
3 years agopvrdma: release device resources in case of an error
Prasad J Pandit [Wed, 12 Dec 2018 17:58:17 +0000 (23:28 +0530)] 
pvrdma: release device resources in case of an error

If during pvrdma device initialisation an error occurs,
pvrdma_realize() does not release memory resources, leading
to memory leakage.

Reported-by: Li Qiang <liq3ea@163.com>
Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
Message-Id: <20181212175817.815-1-ppandit@redhat.com>
Reviewed-by: Yuval Shaia <yuval.shaia@oracle.com>
Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
3 years agodocs: Update pvrdma device documentation
Yuval Shaia [Fri, 21 Dec 2018 14:40:37 +0000 (16:40 +0200)] 
docs: Update pvrdma device documentation

Interface with the device is changed with the addition of support for
MAD packets.
Adjust documentation accordingly.

While there fix a minor mistake which may lead to think that there is a
relation between using RXE on host and the compatibility with bare-metal
peers.

Signed-off-by: Yuval Shaia <yuval.shaia@oracle.com>
Reviewed-by: Marcel Apfelbaum<marcel.apfelbaum@gmail.com>
Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
3 years agohw/rdma: Do not call rdma_backend_del_gid on an empty gid
Yuval Shaia [Fri, 21 Dec 2018 14:40:36 +0000 (16:40 +0200)] 
hw/rdma: Do not call rdma_backend_del_gid on an empty gid

When device goes down the function fini_ports loops over all entries in
gid table regardless of the fact whether entry is valid or not. In case
that entry is not valid we'd like to skip from any further processing in
backend device.

Signed-off-by: Yuval Shaia <yuval.shaia@oracle.com>
Reviewed-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
3 years agohw/rdma: Do not use bitmap_zero_extend to free bitmap
Yuval Shaia [Fri, 21 Dec 2018 14:40:35 +0000 (16:40 +0200)] 
hw/rdma: Do not use bitmap_zero_extend to free bitmap

bitmap_zero_extend is designed to work for extending, not for
shrinking.
Using g_free instead.

Signed-off-by: Yuval Shaia <yuval.shaia@oracle.com>
Reviewed-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
3 years agohw/pvrdma: Clean device's resource when system is shutdown
Yuval Shaia [Fri, 21 Dec 2018 14:40:34 +0000 (16:40 +0200)] 
hw/pvrdma: Clean device's resource when system is shutdown

In order to clean some external resources such as GIDs, QPs etc,
register to receive notification when VM is shutdown.

Signed-off-by: Yuval Shaia <yuval.shaia@oracle.com>
Reviewed-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
3 years agovl: Introduce shutdown_notifiers
Yuval Shaia [Fri, 21 Dec 2018 14:40:33 +0000 (16:40 +0200)] 
vl: Introduce shutdown_notifiers

Notifier will be used for signaling shutdown event to inform system is
shutdown. This will allow devices and other component to run some
cleanup code needed before VM is shutdown.

Signed-off-by: Yuval Shaia <yuval.shaia@oracle.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
3 years agohw/rdma: Remove unneeded code that handles more that one port
Yuval Shaia [Fri, 21 Dec 2018 14:40:32 +0000 (16:40 +0200)] 
hw/rdma: Remove unneeded code that handles more that one port

Device supports only one port, let's remove a dead code that handles
more than one port.

Signed-off-by: Yuval Shaia <yuval.shaia@oracle.com>
Reviewed-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
3 years agohw/pvrdma: Fill error code in command's response
Yuval Shaia [Fri, 21 Dec 2018 14:40:31 +0000 (16:40 +0200)] 
hw/pvrdma: Fill error code in command's response

Driver checks error code let's set it.
In addition, for code simplification purposes, set response's fields
ack, response and err outside of the scope of command handlers.

Signed-off-by: Yuval Shaia <yuval.shaia@oracle.com>
Reviewed-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
3 years agohw/pvrdma: Fill all CQE fields
Yuval Shaia [Fri, 21 Dec 2018 14:40:30 +0000 (16:40 +0200)] 
hw/pvrdma: Fill all CQE fields

Add ability to pass specific WC attributes to CQE such as GRH_BIT flag.

Signed-off-by: Yuval Shaia <yuval.shaia@oracle.com>
Reviewed-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
3 years agohw/pvrdma: Make device state depend on Ethernet function state
Yuval Shaia [Fri, 21 Dec 2018 14:40:29 +0000 (16:40 +0200)] 
hw/pvrdma: Make device state depend on Ethernet function state

User should be able to control the device by changing Ethernet function
state so if user runs 'ifconfig ens3 down' the PVRDMA function should be
down as well.

Signed-off-by: Yuval Shaia <yuval.shaia@oracle.com>
Reviewed-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
3 years agohw/rdma: Initialize node_guid from vmxnet3 mac address
Yuval Shaia [Fri, 21 Dec 2018 14:40:28 +0000 (16:40 +0200)] 
hw/rdma: Initialize node_guid from vmxnet3 mac address

node_guid should be set once device is load.
Make node_guid be GID format (32 bit) of PCI function 0 vmxnet3 device's
MAC.

A new function was added to do the conversion.
So for example the MAC 56:b6:44:e9:62:dc will be converted to GID
54b6:44ff:fee9:62dc.

Signed-off-by: Yuval Shaia <yuval.shaia@oracle.com>
Reviewed-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
3 years agohw/pvrdma: Make sure PCI function 0 is vmxnet3
Yuval Shaia [Fri, 21 Dec 2018 14:40:27 +0000 (16:40 +0200)] 
hw/pvrdma: Make sure PCI function 0 is vmxnet3

Guest driver enforces it, we should also.

Signed-off-by: Yuval Shaia <yuval.shaia@oracle.com>
Reviewed-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
3 years agovmxnet3: Move some definitions to header file
Yuval Shaia [Fri, 21 Dec 2018 14:40:26 +0000 (16:40 +0200)] 
vmxnet3: Move some definitions to header file

pvrdma setup requires vmxnet3 device on PCI function 0 and PVRDMA device
on PCI function 1.
pvrdma device needs to access vmxnet3 device object for several reasons:
1. Make sure PCI function 0 is vmxnet3.
2. To monitor vmxnet3 device state.
3. To configure node_guid accoring to vmxnet3 device's MAC address.

To be able to access vmxnet3 device the definition of VMXNET3State is
moved to a new header file.

Signed-off-by: Yuval Shaia <yuval.shaia@oracle.com>
Reviewed-by: Dmitry Fleytman <dmitry.fleytman@gmail.com>
Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
3 years agohw/pvrdma: Add support to allow guest to configure GID table
Yuval Shaia [Fri, 21 Dec 2018 14:40:25 +0000 (16:40 +0200)] 
hw/pvrdma: Add support to allow guest to configure GID table

The control over the RDMA device's GID table is done by updating the
device's Ethernet function addresses.
Usually the first GID entry is determined by the MAC address, the second
by the first IPv6 address and the third by the IPv4 address. Other
entries can be added by adding more IP addresses. The opposite is the
same, i.e. whenever an address is removed, the corresponding GID entry
is removed.

The process is done by the network and RDMA stacks. Whenever an address
is added the ib_core driver is notified and calls the device driver
add_gid function which in turn update the device.

To support this in pvrdma device we need to hook into the create_bind
and destroy_bind HW commands triggered by pvrdma driver in guest.
Whenever a change is made to the pvrdma port's GID table a special QMP
message is sent to be processed by libvirt to update the address of the
backend Ethernet device.

Signed-off-by: Yuval Shaia <yuval.shaia@oracle.com>
Reviewed-by: Marcel Apfelbaum<marcel.apfelbaum@gmail.com>
Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
3 years agoqapi: Define new QMP message for pvrdma
Yuval Shaia [Fri, 21 Dec 2018 14:40:24 +0000 (16:40 +0200)] 
qapi: Define new QMP message for pvrdma

pvrdma requires that the same GID attached to it will be attached to the
backend device in the host.

A new QMP messages is defined so pvrdma device can broadcast any change
made to its GID table. This event is captured by libvirt which in  turn
will update the GID table in the backend device.

Signed-off-by: Yuval Shaia <yuval.shaia@oracle.com>
Reviewed-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
Acked-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
3 years agohw/pvrdma: Set the correct opcode for send completion
Yuval Shaia [Fri, 21 Dec 2018 14:40:23 +0000 (16:40 +0200)] 
hw/pvrdma: Set the correct opcode for send completion

opcode for WC should be set by the device and not taken from work
element.

Signed-off-by: Yuval Shaia <yuval.shaia@oracle.com>
Reviewed-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
3 years agohw/pvrdma: Set the correct opcode for recv completion
Yuval Shaia [Fri, 21 Dec 2018 14:40:22 +0000 (16:40 +0200)] 
hw/pvrdma: Set the correct opcode for recv completion

The function pvrdma_post_cqe populates CQE entry with opcode from the
given completion element. For receive operation value was not set. Fix
it by setting it to IBV_WC_RECV.

Signed-off-by: Yuval Shaia <yuval.shaia@oracle.com>
Reviewed-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
3 years agohw/pvrdma: Make default pkey 0xFFFF
Yuval Shaia [Fri, 21 Dec 2018 14:40:21 +0000 (16:40 +0200)] 
hw/pvrdma: Make default pkey 0xFFFF

Commit 6e7dba23af ("hw/pvrdma: Make default pkey 0xFFFF") exports
default pkey as external definition but omit the change from 0x7FFF to
0xFFFF.

Fixes: 6e7dba23af ("hw/pvrdma: Make default pkey 0xFFFF")

Signed-off-by: Yuval Shaia <yuval.shaia@oracle.com>
Reviewed-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
3 years agohw/pvrdma: Make function reset_device return void
Yuval Shaia [Fri, 21 Dec 2018 14:40:20 +0000 (16:40 +0200)] 
hw/pvrdma: Make function reset_device return void

This function cannot fail - fix it to return void

Signed-off-by: Yuval Shaia <yuval.shaia@oracle.com>
Reviewed-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
3 years agohw/rdma: Add support for MAD packets
Yuval Shaia [Fri, 21 Dec 2018 14:40:19 +0000 (16:40 +0200)] 
hw/rdma: Add support for MAD packets

MAD (Management Datagram) packets are widely used by various modules
both in kernel and in user space for example the rdma_* API which is
used to create and maintain "connection" layer on top of RDMA uses
several types of MAD packets.

For more information please refer to chapter 13.4 in Volume 1
Architecture Specification, Release 1.1 available here:
https://www.infinibandta.org/ibta-specifications-download/

To support MAD packets the device uses an external utility
(contrib/rdmacm-mux) to relay packets from and to the guest driver.

Signed-off-by: Yuval Shaia <yuval.shaia@oracle.com>
Reviewed-by: Marcel Apfelbaum<marcel.apfelbaum@gmail.com>
Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
3 years agohw/rdma: Abort send-op if fail to create addr handler
Yuval Shaia [Fri, 21 Dec 2018 14:40:18 +0000 (16:40 +0200)] 
hw/rdma: Abort send-op if fail to create addr handler

Function create_ah might return NULL, let's exit with an error.

Signed-off-by: Yuval Shaia <yuval.shaia@oracle.com>
Reviewed-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
3 years agohw/rdma: Return qpn 1 if ibqp is NULL
Yuval Shaia [Fri, 21 Dec 2018 14:40:17 +0000 (16:40 +0200)] 
hw/rdma: Return qpn 1 if ibqp is NULL

Device is not supporting QP0, only QP1.

Signed-off-by: Yuval Shaia <yuval.shaia@oracle.com>
Reviewed-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
3 years agohw/rdma: Add ability to force notification without re-arm
Yuval Shaia [Fri, 21 Dec 2018 14:40:16 +0000 (16:40 +0200)] 
hw/rdma: Add ability to force notification without re-arm

Upon completion of incoming packet the device pushes CQE to driver's RX
ring and notify the driver (msix).
While for data-path incoming packets the driver needs the ability to
control whether it wished to receive interrupts or not, for control-path
packets such as incoming MAD the driver needs to be notified anyway, it
even do not need to re-arm the notification bit.

Enhance the notification field to support this.

Signed-off-by: Yuval Shaia <yuval.shaia@oracle.com>
Reviewed-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
3 years agocontrib/rdmacm-mux: Add implementation of RDMA User MAD multiplexer
Yuval Shaia [Fri, 21 Dec 2018 14:40:15 +0000 (16:40 +0200)] 
contrib/rdmacm-mux: Add implementation of RDMA User MAD multiplexer

RDMA MAD kernel module (ibcm) disallow more than one MAD-agent for a
given MAD class.
This does not go hand-by-hand with qemu pvrdma device's requirements
where each VM is MAD agent.
Fix it by adding implementation of RDMA MAD multiplexer service which on
one hand register as a sole MAD agent with the kernel module and on the
other hand gives service to more than one VM.

Design Overview:
Reviewed-by: Shamir Rabinovitch <shamir.rabinovitch@oracle.com>
----------------
A server process is registered to UMAD framework (for this to work the
rdma_cm kernel module needs to be unloaded) and creates a unix socket to
listen to incoming request from clients.
A client process (such as QEMU) connects to this unix socket and
registers with its own GID.

TX:
----
When client needs to send rdma_cm MAD message it construct it the same
way as without this multiplexer, i.e. creates a umad packet but this
time it writes its content to the socket instead of calling umad_send().
The server, upon receiving such a message fetch local_comm_id from it so
a context for this session can be maintain and relay the message to UMAD
layer by calling umad_send().

RX:
----
The server creates a worker thread to process incoming rdma_cm MAD
messages. When an incoming message arrived (umad_recv()) the server,
depending on the message type (attr_id) looks for target client by
either searching in gid->fd table or in local_comm_id->fd table. With
the extracted fd the server relays to incoming message to the client.

Signed-off-by: Yuval Shaia <yuval.shaia@oracle.com>
Reviewed-by: Shamir Rabinovitch <shamir.rabinovitch@oracle.com>
Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
3 years agohw/pvrdma: Check the correct return value
Yuval Shaia [Thu, 25 Oct 2018 06:17:00 +0000 (09:17 +0300)] 
hw/pvrdma: Check the correct return value

Return value of 0 means ok, we want to free the memory only in case of
error.

Signed-off-by: Yuval Shaia <yuval.shaia@oracle.com>
Message-Id: <20181025061700.17050-1-yuval.shaia@oracle.com>
Reviewed-by: Marcel Apfelbaum<marcel.apfelbaum@gmail.com>
Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
3 years agoMerge remote-tracking branch 'remotes/dgibson/tags/ppc-for-4.0-20181221' into staging
Peter Maydell [Fri, 21 Dec 2018 15:49:59 +0000 (15:49 +0000)] 
Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-4.0-20181221' into staging

ppc patch queue 2018-12-21

This pull request supersedes the one from 2018-12-13.

This is a revised first ppc pull request for qemu-4.0.  Highlights
are:

 * Most of the code for the POWER9 "XIVE" interrupt controller
   (not complete yet, but we're getting there)
 * A number of g_new vs. g_malloc cleanups
 * Some IRQ wiring cleanups
 * A fix for how we advertise NUMA nodes to the guest for pseries

# gpg: Signature made Fri 21 Dec 2018 05:34:12 GMT
# gpg:                using RSA key 6C38CACA20D9B392
# gpg: Good signature from "David Gibson <david@gibson.dropbear.id.au>"
# gpg:                 aka "David Gibson (Red Hat) <dgibson@redhat.com>"
# gpg:                 aka "David Gibson (ozlabs.org) <dgibson@ozlabs.org>"
# gpg:                 aka "David Gibson (kernel.org) <dwg@kernel.org>"
# Primary key fingerprint: 75F4 6586 AE61 A66C C44E  87DC 6C38 CACA 20D9 B392

* remotes/dgibson/tags/ppc-for-4.0-20181221: (40 commits)
  MAINTAINERS: PPC: add a XIVE section
  spapr: change default CPU type to POWER9
  spapr: introduce an 'ic-mode' machine option
  spapr: add an extra OV5 field to the sPAPR IRQ backend
  spapr: add a 'reset' method to the sPAPR IRQ backend
  spapr: extend the sPAPR IRQ backend for XICS migration
  spapr: allocate the interrupt thread context under the CPU core
  spapr: add device tree support for the XIVE exploitation mode
  spapr: add hcalls support for the XIVE exploitation interrupt mode
  spapr: introduce a new machine IRQ backend for XIVE
  spapr-iommu: Always advertise the maximum possible DMA window size
  spapr/xive: use the VCPU id as a NVT identifier
  spapr/xive: introduce a XIVE interrupt controller
  ppc/xive: notify the CPU when the interrupt priority is more privileged
  ppc/xive: introduce a simplified XIVE presenter
  ppc/xive: introduce the XIVE interrupt thread context
  ppc/xive: add support for the END Event State Buffers
  Changes requirement for "vsubsbs" instruction
  spapr: export and rename the xics_max_server_number() routine
  spapr: introduce a spapr_irq_init() routine
  ...

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
3 years agoMerge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging
Peter Maydell [Fri, 21 Dec 2018 14:06:01 +0000 (14:06 +0000)] 
Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging

pci, pc, virtio: fixes, features

VTD fixes
IR and split irqchip are now the default for Q35
ACPI refactoring
hotplug refactoring
new names for virtio devices
multiple pcie link width/speeds
PCI fixes

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
# gpg: Signature made Thu 20 Dec 2018 18:26:03 GMT
# gpg:                using RSA key 281F0DB8D28D5469
# gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>"
# gpg:                 aka "Michael S. Tsirkin <mst@redhat.com>"
# Primary key fingerprint: 0270 606B 6F3C DF3D 0B17  0970 C350 3912 AFBE 8E67
#      Subkey fingerprint: 5D09 FD08 71C8 F85B 94CA  8A0D 281F 0DB8 D28D 5469

* remotes/mst/tags/for_upstream: (44 commits)
  x86-iommu: turn on IR by default if proper
  x86-iommu: switch intr_supported to OnOffAuto type
  q35: set split kernel irqchip as default
  pci: Adjust PCI config limit based on bus topology
  spapr_pci: perform unplug via the hotplug handler
  pci/shpc: perform unplug via the hotplug handler
  pci: Reuse pci-bridge hotplug handler handlers for pcie-pci-bridge
  pci/pcie: perform unplug via the hotplug handler
  pci/pcihp: perform unplug via the hotplug handler
  pci/pcihp: overwrite hotplug handler recursively from the start
  pci/pcihp: perform check for bus capability in pre_plug handler
  s390x/pci: rename hotplug handler callbacks
  pci/shpc: rename hotplug handler callbacks
  pci/pcie: rename hotplug handler callbacks
  hw/i386: Remove deprecated machines pc-0.10 and pc-0.11
  hw: acpi: Remove AcpiRsdpDescriptor and fix tests
  hw: acpi: Export and share the ARM RSDP build
  hw: arm: Support both legacy and current RSDP build
  hw: arm: Convert the RSDP build to the buid_append_foo() API
  hw: arm: Carry RSDP specific data through AcpiRsdpData
  ...

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
3 years agoMAINTAINERS: PPC: add a XIVE section
Cédric Le Goater [Mon, 17 Dec 2018 22:34:45 +0000 (23:34 +0100)] 
MAINTAINERS: PPC: add a XIVE section

Signed-off-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
3 years agospapr: change default CPU type to POWER9
Cédric Le Goater [Mon, 17 Dec 2018 22:34:44 +0000 (23:34 +0100)] 
spapr: change default CPU type to POWER9

Signed-off-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
3 years agospapr: introduce an 'ic-mode' machine option
Cédric Le Goater [Mon, 17 Dec 2018 22:34:43 +0000 (23:34 +0100)] 
spapr: introduce an 'ic-mode' machine option

This option is used to select the interrupt controller mode (XICS or
XIVE) with which the machine will operate. XICS being the default
mode for now.

When running a machine with the XIVE interrupt mode backend, the guest
OS is required to have support for the XIVE exploitation mode. In the
case of legacy OS, the mode selected by CAS should be XICS and the OS
should fail to boot. However, QEMU could possibly detect it, terminate
the boot process and reset to stop in the SLOF firmware. This is not
yet handled.

Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
3 years agospapr: add an extra OV5 field to the sPAPR IRQ backend
Cédric Le Goater [Mon, 17 Dec 2018 22:34:42 +0000 (23:34 +0100)] 
spapr: add an extra OV5 field to the sPAPR IRQ backend

The interrupt modes supported by the hypervisor are advertised to the
guest with new bits definitions of the option vector 5 of property
"ibm,arch-vec-5-platform-support. The byte 23 bits 0-1 of the OV5 are
defined as follow :

  0b00   PAPR 2.7 and earlier (Legacy systems)
  0b01   XIVE Exploitation mode only
  0b10   Either available

If the client/guest selects the XIVE interrupt mode, it informs the
hypervisor by returning the value 0b01 in byte 23 bits 0-1. A 0b00
value indicates the use of the XICS interrupt mode (Legacy systems).

The sPAPR IRQ backend is extended with these definitions and the
values are directly used to populate the "ibm,arch-vec-5-platform-support"
property. The interrupt mode is advertised under TCG and under KVM.
Although a KVM XIVE device is not yet available, the machine can still
operate with kernel_irqchip=off. However, we apply a restriction on
the CPU which is required to be a POWER9 when a XIVE interrupt
controller is in use.

Signed-off-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
3 years agospapr: add a 'reset' method to the sPAPR IRQ backend
Cédric Le Goater [Tue, 11 Dec 2018 22:38:17 +0000 (23:38 +0100)] 
spapr: add a 'reset' method to the sPAPR IRQ backend

For the time being, the XIVE reset handler updates the OS CAM line of
the vCPU as it is done under a real hypervisor when a vCPU is
scheduled to run on a HW thread. This will let the XIVE presenter
engine find a match among the NVTs dispatched on the HW threads.

This handler will become even more useful when we introduce the
machine supporting both interrupt modes, XIVE and XICS. In this
machine, the interrupt mode is chosen by the CAS negotiation process
and activated after a reset.

Signed-off-by: Cédric Le Goater <clg@kaod.org>
[dwg: Fix style nits]
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
3 years agospapr: extend the sPAPR IRQ backend for XICS migration
Cédric Le Goater [Tue, 11 Dec 2018 22:38:16 +0000 (23:38 +0100)] 
spapr: extend the sPAPR IRQ backend for XICS migration

Introduce a new sPAPR IRQ handler to handle resend after migration
when the machine is using a KVM XICS interrupt controller model.

Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
3 years agospapr: allocate the interrupt thread context under the CPU core
Cédric Le Goater [Tue, 11 Dec 2018 22:38:15 +0000 (23:38 +0100)] 
spapr: allocate the interrupt thread context under the CPU core

Each interrupt mode has its own specific interrupt presenter object,
that we store under the CPU object, one for XICS and one for XIVE.

Extend the sPAPR IRQ backend with a new handler to support them both.

Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
3 years agospapr: add device tree support for the XIVE exploitation mode
Cédric Le Goater [Tue, 11 Dec 2018 22:38:14 +0000 (23:38 +0100)] 
spapr: add device tree support for the XIVE exploitation mode

The XIVE interface for the guest is described in the device tree under
the "interrupt-controller" node. A couple of new properties are
specific to XIVE :

 - "reg"

   contains the base address and size of the thread interrupt
   managnement areas (TIMA), for the User level and for the Guest OS
   level. Only the Guest OS level is taken into account today.

 - "ibm,xive-eq-sizes"

   the size of the event queues. One cell per size supported, contains
   log2 of size, in ascending order.

 - "ibm,xive-lisn-ranges"

   the IRQ interrupt number ranges assigned to the guest for the IPIs.

and also under the root node :

 - "ibm,plat-res-int-priorities"

   contains a list of priorities that the hypervisor has reserved for
   its own use. OPAL uses the priority 7 queue to automatically
   escalate interrupts for all other queues (DD2.X POWER9). So only
   priorities [0..6] are allowed for the guest.

Extend the sPAPR IRQ backend with a new handler to populate the DT
with the appropriate "interrupt-controller" node.

Signed-off-by: Cédric Le Goater <clg@kaod.org>
[dwg: Fix style nits]
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
3 years agospapr: add hcalls support for the XIVE exploitation interrupt mode
Cédric Le Goater [Tue, 11 Dec 2018 22:38:13 +0000 (23:38 +0100)] 
spapr: add hcalls support for the XIVE exploitation interrupt mode

The different XIVE virtualization structures (sources and event queues)
are configured with a set of Hypervisor calls :

 - H_INT_GET_SOURCE_INFO

   used to obtain the address of the MMIO page of the Event State
   Buffer (ESB) entry associated with the source.

 - H_INT_SET_SOURCE_CONFIG

   assigns a source to a "target".

 - H_INT_GET_SOURCE_CONFIG

   determines which "target" and "priority" is assigned to a source

 - H_INT_GET_QUEUE_INFO

   returns the address of the notification management page associated
   with the specified "target" and "priority".

 - H_INT_SET_QUEUE_CONFIG

   sets or resets the event queue for a given "target" and "priority".
   It is also used to set the notification configuration associated
   with the queue, only unconditional notification is supported for
   the moment. Reset is performed with a queue size of 0 and queueing
   is disabled in that case.

 - H_INT_GET_QUEUE_CONFIG

   returns the queue settings for a given "target" and "priority".

 - H_INT_RESET

   resets all of the guest's internal interrupt structures to their
   initial state, losing all configuration set via the hcalls
   H_INT_SET_SOURCE_CONFIG and H_INT_SET_QUEUE_CONFIG.

 - H_INT_SYNC

   issue a synchronisation on a source to make sure all notifications
   have reached their queue.

Calls that still need to be addressed :

   H_INT_SET_OS_REPORTING_LINE
   H_INT_GET_OS_REPORTING_LINE

See the code for more documentation on each hcall.

Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
[dwg: Folded in fix for field accessors]
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
3 years agospapr: introduce a new machine IRQ backend for XIVE
Cédric Le Goater [Tue, 11 Dec 2018 22:38:12 +0000 (23:38 +0100)] 
spapr: introduce a new machine IRQ backend for XIVE

The XIVE IRQ backend uses the same layout as the new XICS backend but
covers the full range of the IRQ number space. The IRQ numbers for the
CPU IPIs are allocated at the bottom of this space, below 4K, to
preserve compatibility with XICS which does not use that range.

This should be enough given that the maximum number of CPUs is 1024
for the sPAPR machine under QEMU. For the record, the biggest POWER8
or POWER9 system has a maximum of 1536 HW threads (16 sockets, 192
cores, SMT8).

Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
3 years agospapr-iommu: Always advertise the maximum possible DMA window size
Alexey Kardashevskiy [Fri, 14 Dec 2018 04:21:22 +0000 (15:21 +1100)] 
spapr-iommu: Always advertise the maximum possible DMA window size

When deciding about the huge DMA window, the typical Linux pseries guest
uses the maximum allowed RAM size as the upper limit. We did the same
on QEMU side to match that logic. Now we are going to support a GPU RAM
pass through which is not available at the guest boot time as it requires
the guest driver interaction. As the result, the guest requests a smaller
window than it should. Therefore the guest needs to be patched to
understand this new memory and so does QEMU.

Instead of reimplementing here whatever solution we choose for the guest,
this advertises the biggest possible window size limited by 32 bit
(as defined by LoPAPR). Since the window size has to be power-of-two
(the create rtas call receives a window shift, not a size),
this uses 0x8000.0000 as the maximum number of TCEs possible (rather than
32bit maximum of 0xffff.ffff).

This is safe as:
1. The guest visible emulated table is allocated in KVM (actual pages
are allocated in page fault handler) and QEMU (actual pages are allocated
when updated);
2. The hardware table (and corresponding userspace address table)
supports sparse allocation and also checks for locked_vm limit so
it is unable to cause the host any damage.

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
3 years agospapr/xive: use the VCPU id as a NVT identifier
Cédric Le Goater [Sun, 9 Dec 2018 19:45:57 +0000 (20:45 +0100)] 
spapr/xive: use the VCPU id as a NVT identifier

The IVPE scans the O/S CAM line of the XIVE thread interrupt contexts
to find a matching Notification Virtual Target (NVT) among the NVTs
dispatched on the HW processor threads.

On a real system, the thread interrupt contexts are updated by the
hypervisor when a Virtual Processor is scheduled to run on a HW
thread. Under QEMU, the model will emulate the same behavior by
hardwiring the NVT identifier in the thread context registers at
reset.

The NVT identifier used by the sPAPRXive model is the VCPU id. The END
identifier is also derived from the VCPU id. A set of helpers doing
the conversion between identifiers are provided for the hcalls
configuring the sources and the ENDs.

The model does not need a NVT table but the XiveRouter NVT operations
are provided to perform some extra checks in the routing algorithm.

Signed-off-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
3 years agospapr/xive: introduce a XIVE interrupt controller
Cédric Le Goater [Sun, 9 Dec 2018 19:45:56 +0000 (20:45 +0100)] 
spapr/xive: introduce a XIVE interrupt controller

sPAPRXive models the XIVE interrupt controller of the sPAPR machine.
It inherits from the XiveRouter and provisions storage for the routing
tables :

  - Event Assignment Structure (EAS)
  - Event Notification Descriptor (END)

The sPAPRXive model incorporates an internal XiveSource for the IPIs
and for the interrupts of the virtual devices of the guest. This model
is consistent with XIVE architecture which also incorporates an
internal IVSE for IPIs and accelerator interrupts in the IVRE
sub-engine.

The sPAPRXive model exports two memory regions, one for the ESB
trigger and management pages used to control the sources and one for
the TIMA pages. They are mapped by default at the addresses found on
chip 0 of a baremetal system. This is also consistent with the XIVE
architecture which defines a Virtualization Controller BAR for the
internal IVSE ESB pages and a Thread Managment BAR for the TIMA.

Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
[dwg: Fold in field accessor fixes]
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
3 years agoppc/xive: notify the CPU when the interrupt priority is more privileged
Cédric Le Goater [Sun, 9 Dec 2018 19:45:55 +0000 (20:45 +0100)] 
ppc/xive: notify the CPU when the interrupt priority is more privileged

After the event data was enqueued in the O/S Event Queue, the IVPE
raises the bit corresponding to the priority of the pending interrupt
in the register IBP (Interrupt Pending Buffer) to indicate there is an
event pending in one of the 8 priority queues. The Pending Interrupt
Priority Register (PIPR) is also updated using the IPB. This register
represent the priority of the most favored pending notification.

The PIPR is then compared to the the Current Processor Priority
Register (CPPR). If it is more favored (numerically less than), the
CPU interrupt line is raised and the EO bit of the Notification Source
Register (NSR) is updated to notify the presence of an exception for
the O/S. The check needs to be done whenever the PIPR or the CPPR are
changed.

The O/S acknowledges the interrupt with a special load in the Thread
Interrupt Management Area. If the EO bit of the NSR is set, the CPPR
takes the value of PIPR. The bit number in the IBP corresponding to
the priority of the pending interrupt is reseted and so is the EO bit
of the NSR.

Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
[dwg: Fix style nits]
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
3 years agoppc/xive: introduce a simplified XIVE presenter
Cédric Le Goater [Sun, 9 Dec 2018 19:45:54 +0000 (20:45 +0100)] 
ppc/xive: introduce a simplified XIVE presenter

The last sub-engine of the XIVE architecture is the Interrupt
Virtualization Presentation Engine (IVPE). On HW, the IVRE and the
IVPE share elements, the Power Bus interface (CQ), the routing table
descriptors, and they can be combined in the same HW logic. We do the
same in QEMU and combine both engines in the XiveRouter for
simplicity.

When the IVRE has completed its job of matching an event source with a
Notification Virtual Target (NVT) to notify, it forwards the event
notification to the IVPE sub-engine. The IVPE scans the thread
interrupt contexts of the Notification Virtual Targets (NVT)
dispatched on the HW processor threads and if a match is found, it
signals the thread. If not, the IVPE escalates the notification to
some other targets and records the notification in a backlog queue.

The IVPE maintains the thread interrupt context state for each of its
NVTs not dispatched on HW processor threads in the Notification
Virtual Target table (NVTT).

The model currently only supports single NVT notifications.

Signed-off-by: Cédric Le Goater <clg@kaod.org>
[dwg: Folded in fix for field accessors]
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
3 years agoppc/xive: introduce the XIVE interrupt thread context
Cédric Le Goater [Sun, 9 Dec 2018 19:45:53 +0000 (20:45 +0100)] 
ppc/xive: introduce the XIVE interrupt thread context

Each POWER9 processor chip has a XIVE presenter that can generate four
different exceptions to its threads:

  - hypervisor exception,
  - O/S exception
  - Event-Based Branch (EBB)
  - msgsnd (doorbell).

Each exception has a state independent from the others called a Thread
Interrupt Management context. This context is a set of registers which
lets the thread handle priority management and interrupt acknowledgment
among other things. The most important ones being :

  - Interrupt Priority Register  (PIPR)
  - Interrupt Pending Buffer     (IPB)
  - Current Processor Priority   (CPPR)
  - Notification Source Register (NSR)

These registers are accessible through a specific MMIO region, called
the Thread Interrupt Management Area (TIMA), four aligned pages, each
exposing a different view of the registers. First page (page address
ending in 0b00) gives access to the entire context and is reserved for
the ring 0 view for the physical thread context. The second (page
address ending in 0b01) is for the hypervisor, ring 1 view. The third
(page address ending in 0b10) is for the operating system, ring 2
view. The fourth (page address ending in 0b11) is for user level, ring
3 view.

The thread interrupt context is modeled with a XiveTCTX object
containing the values of the different exception registers. The TIMA
region is mapped at the same address for each CPU.

Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
3 years agoppc/xive: add support for the END Event State Buffers
Cédric Le Goater [Sun, 9 Dec 2018 19:45:52 +0000 (20:45 +0100)] 
ppc/xive: add support for the END Event State Buffers

The Event Notification Descriptor (END) XIVE structure also contains
two Event State Buffers providing further coalescing of interrupts,
one for the notification event (ESn) and one for the escalation events
(ESe). A MMIO page is assigned for each to control the EOI through
loads only. Stores are not allowed.

The END ESBs are modeled through an object resembling the 'XiveSource'
It is stateless as the END state bits are backed into the XiveEND
structure under the XiveRouter and the MMIO accesses follow the same
rules as for the XiveSource ESBs.

END ESBs are not supported by the Linux drivers neither on OPAL nor on
sPAPR. Nevetherless, it provides a mean to study the question in the
future and validates a bit more the XIVE model.

Signed-off-by: Cédric Le Goater <clg@kaod.org>
[dwg: Fold in a later fix for field access]
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
3 years agoChanges requirement for "vsubsbs" instruction
Paul A. Clarke [Fri, 7 Dec 2018 17:13:14 +0000 (15:13 -0200)] 
Changes requirement for "vsubsbs" instruction

Changes requirement for "vsubsbs" instruction, which has been supported
since ISA 2.03. (Please see section 5.9.1.2 of ISA 2.03)

Reported-by: Paul A. Clarke <pc@us.ibm.com>
Signed-off-by: Paul A. Clarke <pc@us.ibm.com>
Signed-off-by: Leonardo Bras <leonardo@linux.vnet.ibm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
3 years agospapr: export and rename the xics_max_server_number() routine
Cédric Le Goater [Wed, 5 Dec 2018 23:22:29 +0000 (00:22 +0100)] 
spapr: export and rename the xics_max_server_number() routine

The XIVE sPAPR IRQ backend will use it to define the number of ENDs of
the IC controller.

Signed-off-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
3 years agospapr: introduce a spapr_irq_init() routine
Cédric Le Goater [Wed, 5 Dec 2018 23:22:27 +0000 (00:22 +0100)] 
spapr: introduce a spapr_irq_init() routine

Initialize the MSI bitmap from it as this will be necessary for the
sPAPR IRQ backend for XIVE.

Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
3 years agospapr: initialize VSMT before initializing the IRQ backend
Cédric Le Goater [Wed, 5 Dec 2018 23:22:26 +0000 (00:22 +0100)] 
spapr: initialize VSMT before initializing the IRQ backend

We will need to use xics_max_server_number() to create the sPAPRXive
object modeling the interrupt controller of the machine which is
created before the CPUs.

Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Greg Kurz <groug@kaod.org>
[dwg: Fix style nit]
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
3 years agoppc/xive: introduce the XIVE Event Notification Descriptors
Cédric Le Goater [Wed, 5 Dec 2018 23:22:19 +0000 (00:22 +0100)] 
ppc/xive: introduce the XIVE Event Notification Descriptors

To complete the event routing, the IVRE sub-engine uses a second table
containing Event Notification Descriptor (END) structures.

An END specifies on which Event Queue (EQ) the event notification
data, defined in the associated EAS, should be posted when an
exception occurs. It also defines which Notification Virtual Target
(NVT) should be notified.

The Event Queue is a memory page provided by the O/S defining a
circular buffer, one per server and priority couple, containing Event
Queue entries. These are 4 bytes long, the first bit being a
'generation' bit and the 31 following bits the END Data field. They
are pulled by the O/S when the exception occurs.

The END Data field is a way to set an invariant logical event source
number for an IRQ. On sPAPR machines, it is set with the
H_INT_SET_SOURCE_CONFIG hcall when the EISN flag is used.

Signed-off-by: Cédric Le Goater <clg@kaod.org>
[dwg: Fold in a later fix from Cédric fixing field accessors]
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
3 years agoppc/xive: introduce the XiveRouter model
Cédric Le Goater [Wed, 5 Dec 2018 23:22:18 +0000 (00:22 +0100)] 
ppc/xive: introduce the XiveRouter model

The XiveRouter models the second sub-engine of the XIVE architecture :
the Interrupt Virtualization Routing Engine (IVRE).

The IVRE handles event notifications of the IVSE and performs the
interrupt routing process. For this purpose, it uses a set of tables
stored in system memory, the first of which being the Event Assignment
Structure (EAS) table.

The EAT associates an interrupt source number with an Event Notification
Descriptor (END) which will be used in a second phase of the routing
process to identify a Notification Virtual Target.

The XiveRouter is an abstract class which needs to be inherited from
to define a storage for the EAT, and other upcoming tables.

Signed-off-by: Cédric Le Goater <clg@kaod.org>
[dwg: Folded in parts of a later fix by Cédric fixing field access]
[dwg: Fix style nits]
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
3 years agoppc/xive: introduce the XiveNotifier interface
Cédric Le Goater [Wed, 5 Dec 2018 23:22:17 +0000 (00:22 +0100)] 
ppc/xive: introduce the XiveNotifier interface

The XiveNotifier offers a simple interface, between the XiveSource
object and the main interrupt controller of the machine. It will
forward event notifications to the XIVE Interrupt Virtualization
Routing Engine (IVRE).

Signed-off-by: Cédric Le Goater <clg@kaod.org>
[dwg: Adjust type name string for XiveNotifier]
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
3 years agoppc/xive: add support for the LSI interrupt sources
Cédric Le Goater [Wed, 5 Dec 2018 23:22:16 +0000 (00:22 +0100)] 
ppc/xive: add support for the LSI interrupt sources

The 'sent' status of the LSI interrupt source is modeled with the 'P'
bit of the ESB and the assertion status of the source is maintained
with an extra bit under the main XiveSource object. The type of the
source is stored in the same array for practical reasons.

Signed-off-by: Cédric Le Goater <clg@kaod.org>
[dwg: Fix style nit]
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
3 years agoppc/xive: introduce a XIVE interrupt source model
Cédric Le Goater [Wed, 5 Dec 2018 23:22:15 +0000 (00:22 +0100)] 
ppc/xive: introduce a XIVE interrupt source model

The first sub-engine of the overall XIVE architecture is the Interrupt
Virtualization Source Engine (IVSE). An IVSE can be integrated into
another logic, like in a PCI PHB or in the main interrupt controller
to manage IPIs.

Each IVSE instance is associated with an Event State Buffer (ESB) that
contains a two bit state entry for each possible event source. When an
event is signaled to the IVSE, by MMIO or some other means, the
associated interrupt state bits are fetched from the ESB and
modified. Depending on the resulting ESB state, the event is forwarded
to the IVRE sub-engine of the controller doing the routing.

Each supported ESB entry is associated with either a single or a
even/odd pair of pages which provides commands to manage the source:
to EOI, to turn off the source for instance.

On a sPAPR machine, the O/S will obtain the page address of the ESB
entry associated with a source and its characteristic using the
H_INT_GET_SOURCE_INFO hcall. On PowerNV, a similar OPAL call is used.

The xive_source_notify() routine is in charge forwarding the source
event notification to the routing engine. It will be filled later on.

Signed-off-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
3 years agoe500: simplify IRQ wiring
Greg Kurz [Tue, 27 Nov 2018 13:06:31 +0000 (14:06 +0100)] 
e500: simplify IRQ wiring

The OpenPIC have 5 outputs per connected CPU. The machine init code hence
needs a bi-dimensional array (smp_cpu lines, 5 columns) to wire up the irqs
between the PIC and the CPUs.

The current code first allocates an array of smp_cpus pointers to qemu_irq
type, then it allocates another array of smp_cpus * 5 qemu_irq and fills the
first array with pointers to each line of the second array. This is rather
convoluted.

Simplify the logic by introducing a structured type that describes all the
OpenPIC outputs for a single CPU, ie, fixed size of 5 qemu_irq, and only
allocate a smp_cpu sized array of those.

This also allows to use g_new(T, n) instead of g_malloc(sizeof(T) * n)
as recommended in HACKING.

Signed-off-by: Greg Kurz <groug@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
3 years agomac_newworld: simplify IRQ wiring
Greg Kurz [Tue, 27 Nov 2018 13:06:22 +0000 (14:06 +0100)] 
mac_newworld: simplify IRQ wiring

The OpenPIC have 5 outputs per connected CPU. The machine init code hence
needs a bi-dimensional array (smp_cpu lines, 5 columns) to wire up the irqs
between the PIC and the CPUs.

The current code first allocates an array of smp_cpus pointers to qemu_irq
type, then it allocates another array of smp_cpus * 5 qemu_irq and fills the
first array with pointers to each line of the second array. This is rather
convoluted.

Simplify the logic by introducing a structured type that describes all the
OpenPIC outputs for a single CPU, ie, fixed size of 5 qemu_irq, and only
allocate a smp_cpu sized array of those.

This also allows to use g_new(T, n) instead of g_malloc(sizeof(T) * n)
as recommended in HACKING.

Signed-off-by: Greg Kurz <groug@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
3 years agovirtex_ml507: use g_new(T, n) instead of g_malloc(sizeof(T) * n)
Greg Kurz [Tue, 27 Nov 2018 13:06:12 +0000 (14:06 +0100)] 
virtex_ml507: use g_new(T, n) instead of g_malloc(sizeof(T) * n)

Because it is a recommended coding practice (see HACKING).

Signed-off-by: Greg Kurz <groug@kaod.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
3 years agosam460ex: use g_new(T, n) instead of g_malloc(sizeof(T) * n)
Greg Kurz [Tue, 27 Nov 2018 13:06:01 +0000 (14:06 +0100)] 
sam460ex: use g_new(T, n) instead of g_malloc(sizeof(T) * n)

Because it is a recommended coding practice (see HACKING).

Signed-off-by: Greg Kurz <groug@kaod.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
3 years agoppc440_bamboo: use g_new(T, n) instead of g_malloc(sizeof(T) * n)
Greg Kurz [Tue, 27 Nov 2018 13:05:51 +0000 (14:05 +0100)] 
ppc440_bamboo: use g_new(T, n) instead of g_malloc(sizeof(T) * n)

Because it is a recommended coding practice (see HACKING).

Signed-off-by: Greg Kurz <groug@kaod.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
3 years agoppc405_uc: use g_new(T, n) instead of g_malloc(sizeof(T) * n)
Greg Kurz [Tue, 27 Nov 2018 13:05:38 +0000 (14:05 +0100)] 
ppc405_uc: use g_new(T, n) instead of g_malloc(sizeof(T) * n)

Because it is a recommended coding practice (see HACKING).

Signed-off-by: Greg Kurz <groug@kaod.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
3 years agoppc405_boards: use g_new(T, n) instead of g_malloc(sizeof(T) * n)
Greg Kurz [Tue, 27 Nov 2018 13:05:29 +0000 (14:05 +0100)] 
ppc405_boards: use g_new(T, n) instead of g_malloc(sizeof(T) * n)

Because it is a recommended coding practice (see HACKING).

Signed-off-by: Greg Kurz <groug@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
3 years agospapr: use g_new(T, n) instead of g_malloc(sizeof(T) * n)
Greg Kurz [Tue, 27 Nov 2018 13:05:18 +0000 (14:05 +0100)] 
spapr: use g_new(T, n) instead of g_malloc(sizeof(T) * n)

Because it is a recommended coding practice (see HACKING).

Signed-off-by: Greg Kurz <groug@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
3 years agotarget/ppc: use g_new(T, n) instead of g_malloc(sizeof(T) * n)
Greg Kurz [Tue, 27 Nov 2018 13:05:06 +0000 (14:05 +0100)] 
target/ppc: use g_new(T, n) instead of g_malloc(sizeof(T) * n)

Because it is a recommended coding practice (see HACKING).

Signed-off-by: Greg Kurz <groug@kaod.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
3 years agospapr: drop redundant statement in spapr_populate_drconf_memory()
Greg Kurz [Thu, 22 Nov 2018 14:31:36 +0000 (15:31 +0100)] 
spapr: drop redundant statement in spapr_populate_drconf_memory()

Signed-off-by: Greg Kurz <groug@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Laurent Vivier <laurent@vivier.eu>
3 years agotarget/ppc: tcg: Implement addex instruction
Suraj Jitindar Singh [Thu, 15 Nov 2018 03:22:59 +0000 (14:22 +1100)] 
target/ppc: tcg: Implement addex instruction

Implement the addex instruction introduced in ISA V3.00 in qemu tcg.

The add extended using alternate carry bit (addex) instruction performs
the same operation as the add extended (adde) instruction, but using the
overflow (ov) field in the fixed point exception register (xer) as the
carry in and out instead of the carry (ca) field.

The instruction has a Z23-form, not an XO form, as follows:

    ------------------------------------------------------------------
    |   31   |   RT   |   RA   |   RB   |   CY   |     170     |  0  |
    ------------------------------------------------------------------
    0        6        11       16       21       23            31    32

However since the only valid form of the instruction defined so far is
CY = 0, we can treat this like an XO form instruction.

There is no dot form (addex.) of the instruction and the summary overflow
(so) bit in the xer is not modified by this instruction.

For simplicity we reuse the gen_op_arith_add function and add a function
argument to specify where the carry in input should come from and the
carry out output be stored (note must be the same location).

Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
3 years agospapr: Fix ibm,max-associativity-domains property number of nodes
Serhii Popovych [Thu, 22 Nov 2018 13:19:27 +0000 (08:19 -0500)] 
spapr: Fix ibm,max-associativity-domains property number of nodes

Laurent Vivier reported off by one with maximum number of NUMA nodes
provided by qemu-kvm being less by one than required according to
description of "ibm,max-associativity-domains" property in LoPAPR.

It appears that I incorrectly treated LoPAPR description of this
property assuming it provides last valid domain (NUMA node here)
instead of maximum number of domains.

  ### Before hot-add

  (qemu) info numa
  3 nodes
  node 0 cpus: 0
  node 0 size: 0 MB
  node 0 plugged: 0 MB
  node 1 cpus:
  node 1 size: 1024 MB
  node 1 plugged: 0 MB
  node 2 cpus:
  node 2 size: 0 MB
  node 2 plugged: 0 MB

  $ numactl -H
  available: 2 nodes (0-1)
  node 0 cpus: 0
  node 0 size: 0 MB
  node 0 free: 0 MB
  node 1 cpus:
  node 1 size: 999 MB
  node 1 free: 658 MB
  node distances:
  node   0   1
    0:  10  40
    1:  40  10

  ### Hot-add

  (qemu) object_add memory-backend-ram,id=mem0,size=1G
  (qemu) device_add pc-dimm,id=dimm1,memdev=mem0,node=2
  (qemu) [   87.704898] pseries-hotplug-mem: Attempting to hot-add 4 ...
  <there is no "Initmem setup node 2 [mem 0xHEX-0xHEX]">
  [   87.705128] lpar: Attempting to resize HPT to shift 21
  ... <HPT resize messages>

  ### After hot-add

  (qemu) info numa
  3 nodes
  node 0 cpus: 0
  node 0 size: 0 MB
  node 0 plugged: 0 MB
  node 1 cpus:
  node 1 size: 1024 MB
  node 1 plugged: 0 MB
  node 2 cpus:
  node 2 size: 1024 MB
  node 2 plugged: 1024 MB

  $ numactl -H
  available: 2 nodes (0-1)
  ^^^^^^^^^^^^^^^^^^^^^^^^
             Still only two nodes (and memory hot-added to node 0 below)
  node 0 cpus: 0
  node 0 size: 1024 MB
  node 0 free: 1021 MB
  node 1 cpus:
  node 1 size: 999 MB
  node 1 free: 658 MB
  node distances:
  node   0   1
    0:  10  40
    1:  40  10

After fix applied numactl(8) reports 3 nodes available and memory
plugged into node 2 as expected.

From David Gibson:
------------------
  Qemu makes a distinction between "non NUMA" (nb_numa_nodes == 0) and
  "NUMA with one node" (nb_numa_nodes == 1).  But from a PAPR guests's
  point of view these are equivalent.  I don't want to present two
  different cases to the guest when we don't need to, so even though the
  guest can handle it, I'd prefer we put a '1' here for both the
  nb_numa_nodes == 0 and nb_numa_nodes == 1 case.

This consolidates everything discussed previously on mailing list.

Fixes: da9f80fbad21 ("spapr: Add ibm,max-associativity-domains property")
Reported-by: Laurent Vivier <lvivier@redhat.com>
Signed-off-by: Serhii Popovych <spopovyc@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Greg Kurz <groug@kaod.org>
Reviewed-by: Laurent Vivier <lvivier@redhat.com>
3 years agotarget/ppc: Remove silly GETFIELD/SETFIELD/MASK_TO_LSH macros
David Gibson [Wed, 19 Dec 2018 01:26:20 +0000 (12:26 +1100)] 
target/ppc: Remove silly GETFIELD/SETFIELD/MASK_TO_LSH macros

The (only) obvious use for these macros is constructing and parsing guest
visible register fields.  But the way they're constructed, they're only
valid when used on a *host* long, whose size shouldn't be visible to the
guest at all.

They also have no current users, so just get rid of them.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
3 years agotarget/ppc: fix the PPC_BIT definitions
Cédric Le Goater [Mon, 17 Dec 2018 22:34:39 +0000 (23:34 +0100)] 
target/ppc: fix the PPC_BIT definitions

Change the PPC_BIT macro to use ULL instead of UL and the PPC_BIT32
and PPC_BIT8 not to use any suffix.

This fixes a compile breakage on windows.

Signed-off-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
3 years agoMerge remote-tracking branch 'remotes/cohuck/tags/s390x-20181220' into staging
Peter Maydell [Thu, 20 Dec 2018 20:39:04 +0000 (20:39 +0000)] 
Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20181220' into staging

Two s390x bugfixes.

# gpg: Signature made Thu 20 Dec 2018 16:36:42 GMT
# gpg:                using RSA key DECF6B93C6F02FAF
# gpg: Good signature from "Cornelia Huck <conny@cornelia-huck.de>"
# gpg:                 aka "Cornelia Huck <huckc@linux.vnet.ibm.com>"
# gpg:                 aka "Cornelia Huck <cornelia.huck@de.ibm.com>"
# gpg:                 aka "Cornelia Huck <cohuck@kernel.org>"
# gpg:                 aka "Cornelia Huck <cohuck@redhat.com>"
# Primary key fingerprint: C3D0 D66D C362 4FF6 A8C0  18CE DECF 6B93 C6F0 2FAF

* remotes/cohuck/tags/s390x-20181220:
  hw/s390x: Fix bad mask in time2tod()
  hw/s390/ccw.c: Don't take address of packed members

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
3 years agoMerge remote-tracking branch 'remotes/armbru/tags/pull-misc-2018-12-20' into staging
Peter Maydell [Thu, 20 Dec 2018 18:54:46 +0000 (18:54 +0000)] 
Merge remote-tracking branch 'remotes/armbru/tags/pull-misc-2018-12-20' into staging

Miscellaneous patches for 2018-12-20

# gpg: Signature made Thu 20 Dec 2018 09:36:27 GMT
# gpg:                using RSA key 3870B400EB918653
# gpg: Good signature from "Markus Armbruster <armbru@redhat.com>"
# gpg:                 aka "Markus Armbruster <armbru@pond.sub.org>"
# Primary key fingerprint: 354B C8B3 D7EB 2A6B 6867  4E5F 3870 B400 EB91 8653

* remotes/armbru/tags/pull-misc-2018-12-20:
  build: Remake config-host.mak when VERSION changes
  Clean up includes

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
3 years agox86-iommu: turn on IR by default if proper
Peter Xu [Thu, 20 Dec 2018 05:40:37 +0000 (13:40 +0800)] 
x86-iommu: turn on IR by default if proper

When the user didn't specify "intremap" for the IOMMU device, we turn
it on by default if it is supported.  This will turn IR on for the
default Q35 platform as long as the IOMMU device is specified on new
kernels.

Signed-off-by: Peter Xu <peterx@redhat.com>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
3 years agox86-iommu: switch intr_supported to OnOffAuto type
Peter Xu [Thu, 20 Dec 2018 05:40:36 +0000 (13:40 +0800)] 
x86-iommu: switch intr_supported to OnOffAuto type

Switch the intr_supported variable from a boolean to OnOffAuto type so
that we can know whether the user specified it or not.  With that
we'll have a chance to help the user to choose more wisely where
possible.  Introduce x86_iommu_ir_supported() to mask these changes.

No functional change at all.

Signed-off-by: Peter Xu <peterx@redhat.com>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
3 years agoq35: set split kernel irqchip as default
Peter Xu [Thu, 20 Dec 2018 05:40:35 +0000 (13:40 +0800)] 
q35: set split kernel irqchip as default

Starting from QEMU 4.0, let's specify "split" as the default value for
kernel-irqchip.

So for QEMU>=4.0 we'll have: allowed=Y,required=N,split=Y
   for QEMU<=3.1 we'll have: allowed=Y,required=N,split=N
   (omitting all the "kernel_irqchip_" prefix)

Note that this will let the default q35 machine type to depend on
Linux version 4.4 or newer because that's where split irqchip is
introduced in kernel.  But it's fine since we're boosting supported
Linux version for QEMU 4.0 to around Linux 4.5.  For more information
please refer to the discussion on AMD's RDTSCP:

  https://lore.kernel.org/lkml/20181210181328.GA762@zn.tnic/

Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
3 years agopci: Adjust PCI config limit based on bus topology
Alex Williamson [Mon, 18 Jan 2016 23:06:03 +0000 (16:06 -0700)] 
pci: Adjust PCI config limit based on bus topology

A conventional PCI bus does not support config space accesses above
the standard 256 byte configuration space.  PCIe-to-PCI bridges are
not permitted to forward transactions if the extended register address
field is non-zero and must handle it as an unsupported request (PCIe
bridge spec rev 1.0, 4.1.3, 4.1.4).  Therefore, we should not support
extended config space if there is a conventional bus anywhere on the
path to a device.

Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Reviewed-by: Marcel Apfelbaum <marcel@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
3 years agospapr_pci: perform unplug via the hotplug handler
David Hildenbrand [Wed, 12 Dec 2018 09:16:23 +0000 (10:16 +0100)] 
spapr_pci: perform unplug via the hotplug handler

Introduce and use the "unplug" callback.

This is a preparation for multi-stage hotplug handlers, whereby the bus
hotplug handler is overwritten by the machine hotplug handler. This handler
will then pass control to the bus hotplug handler. So to get this running
cleanly, we also have to make sure to go via the hotplug handler chain when
actually unplugging a device after an unplug request. Lookup the hotplug
handler and call "unplug".

Reviewed-by: Greg Kurz <groug@kaod.org>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
3 years agopci/shpc: perform unplug via the hotplug handler
David Hildenbrand [Wed, 12 Dec 2018 09:16:22 +0000 (10:16 +0100)] 
pci/shpc: perform unplug via the hotplug handler

Introduce and use the "unplug" callback.

This is a preparation for multi-stage hotplug handlers, whereby the bus
hotplug handler is overwritten by the machine hotplug handler. This handler
will then pass control to the bus hotplug handler. So to get this running
cleanly, we also have to make sure to go via the hotplug handler chain when
actually unplugging a device after an unplug request. Lookup the hotplug
handler and call "unplug".

Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
3 years agopci: Reuse pci-bridge hotplug handler handlers for pcie-pci-bridge
David Hildenbrand [Wed, 12 Dec 2018 09:16:21 +0000 (10:16 +0100)] 
pci: Reuse pci-bridge hotplug handler handlers for pcie-pci-bridge

These functions are essentially the same, we only have to use
object_get_typename() for reporting errors. So let's share the
implementation of hotplug handler callbacks.

Suggested-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
3 years agopci/pcie: perform unplug via the hotplug handler
David Hildenbrand [Wed, 12 Dec 2018 09:16:20 +0000 (10:16 +0100)] 
pci/pcie: perform unplug via the hotplug handler

Introduce and use the "unplug" callback.

This is a preparation for multi-stage hotplug handlers, whereby the bus
hotplug handler is overwritten by the machine hotplug handler. This handler
will then pass control to the bus hotplug handler. So to get this running
cleanly, we also have to make sure to go via the hotplug handler chain when
actually unplugging a device after an unplug request. Lookup the hotplug
handler and call "unplug".

Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
3 years agopci/pcihp: perform unplug via the hotplug handler
David Hildenbrand [Wed, 12 Dec 2018 09:16:19 +0000 (10:16 +0100)] 
pci/pcihp: perform unplug via the hotplug handler

Introduce and use the "unplug" callback.

This is a preparation for multi-stage hotplug handlers, whereby the bus
hotplug handler is overwritten by the machine hotplug handler. This handler
will then pass control to the bus hotplug handler. So to get this running
cleanly, we also have to make sure to go via the hotplug handler chain when
actually unplugging a device after an unplug request. Lookup the hotplug
handler and call "unplug".

Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
3 years agopci/pcihp: overwrite hotplug handler recursively from the start
David Hildenbrand [Wed, 12 Dec 2018 09:16:18 +0000 (10:16 +0100)] 
pci/pcihp: overwrite hotplug handler recursively from the start

For now, the hotplug handler is not called for devices that are
being cold plugged. The hotplug handler is setup when the machine
initialization is fully done. Only bridges that were cold plugged are
considered.

Set the hotplug handler for the root piix bus directly when realizing.
Overwrite the hotplug handler of bridges when coldplugging them.

This will now make sure that the ACPI PCI hotplug handler is also called
for cold plugged devices (also on bridges) but not for bridges that were
hotplugged (keeping the current behavior).

Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
3 years agopci/pcihp: perform check for bus capability in pre_plug handler
David Hildenbrand [Wed, 12 Dec 2018 09:16:17 +0000 (10:16 +0100)] 
pci/pcihp: perform check for bus capability in pre_plug handler

Perform the check in the pre_plug handler. In addition, we need the
capability only if the device is actually hotplugged (and not created
during machine initialization). This is a preparation for coldplugging
pci devices via that hotplug handler.

Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
3 years agos390x/pci: rename hotplug handler callbacks
David Hildenbrand [Wed, 12 Dec 2018 09:16:15 +0000 (10:16 +0100)] 
s390x/pci: rename hotplug handler callbacks

The callbacks are also called for cold plugged devices. Drop the "hot"
to better match the actual callback names.

Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Pierre Morel<pmorel@linux.ibm.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
3 years agopci/shpc: rename hotplug handler callbacks
David Hildenbrand [Wed, 12 Dec 2018 09:16:14 +0000 (10:16 +0100)] 
pci/shpc: rename hotplug handler callbacks

The callbacks are also called for cold plugged devices. Drop the "hot"
to better match the actual callback names.

While at it, also rename shpc_device_hotplug_common() to
shpc_device_plug_common().

Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
3 years agopci/pcie: rename hotplug handler callbacks
David Hildenbrand [Wed, 12 Dec 2018 09:16:13 +0000 (10:16 +0100)] 
pci/pcie: rename hotplug handler callbacks

The callbacks are also called for cold plugged devices. Drop the "hot"
to better match the actual callback names.

While at it, also rename  pcie_cap_slot_hotplug_common() to
pcie_cap_slot_plug_common().

Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
3 years agohw/i386: Remove deprecated machines pc-0.10 and pc-0.11
Thomas Huth [Mon, 17 Dec 2018 16:57:37 +0000 (17:57 +0100)] 
hw/i386: Remove deprecated machines pc-0.10 and pc-0.11

They've been deprecated for two releases and nobody complained that they
are still required anymore, so it's time to remove these now.
And while we're at it, mark the other remaining old 0.x machine types
as deprecated (since they can not properly be used for live-migration
anyway).

Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
3 years agohw: acpi: Remove AcpiRsdpDescriptor and fix tests
Samuel Ortiz [Thu, 20 Dec 2018 15:02:55 +0000 (16:02 +0100)] 
hw: acpi: Remove AcpiRsdpDescriptor and fix tests

The only remaining AcpiRsdpDescriptor users are the ACPI utils for the
BIOS table tests.
We remove that dependency and can thus remove the structure itself.

Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Andrew Jones <drjones@redhat.com>
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
3 years agohw/s390x: Fix bad mask in time2tod()
Thomas Huth [Fri, 14 Dec 2018 13:08:07 +0000 (14:08 +0100)] 
hw/s390x: Fix bad mask in time2tod()

Since "s390x/tcg: avoid overflows in time2tod/tod2time", the
time2tod() function tries to deal with the 9 uppermost bits in the
time value, but uses the wrong mask for this: 0xff80000000000000 should
be used instead of 0xff10000000000000 here.

Fixes: 14055ce53c2d901d826ffad7fb7d6bb8ab46bdfd
Cc: qemu-stable@nongnu.org
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-Id: <1544792887-14575-1-git-send-email-thuth@redhat.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
[CH: tweaked commit message]
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
3 years agohw/s390/ccw.c: Don't take address of packed members
Peter Maydell [Thu, 13 Dec 2018 12:02:52 +0000 (12:02 +0000)] 
hw/s390/ccw.c: Don't take address of packed members

Taking the address of a field in a packed struct is a bad idea, because
it might not be actually aligned enough for that pointer type (and
thus cause a crash on dereference on some host architectures). Newer
versions of clang warn about this.

Avoid the problem by using local copies of the PMCW and SCSW
struct fields in copy_schib_from_guest() and copy_schib_to_guest().

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20181213120252.21697-1-peter.maydell@linaro.org>
Reviewed-by: Farhan Ali <alifm@linux.ibm.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
3 years agobuild: Remake config-host.mak when VERSION changes
Markus Armbruster [Fri, 14 Dec 2018 08:47:54 +0000 (09:47 +0100)] 
build: Remake config-host.mak when VERSION changes

configure gets the version number from VERSION, and writes it to
config-host.mak.  The make dependency for that is missing.  Because of
that, a rebuild after a VERSION change may not pick up the change.
Fix that.

Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20181214084754.23854-1-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
3 years agoClean up includes
Markus Armbruster [Tue, 4 Dec 2018 17:25:35 +0000 (18:25 +0100)] 
Clean up includes

Clean up includes so that osdep.h is included first and headers
which it implies are not included manually.

This commit was created with scripts/clean-includes, with the changes
to the following files manually reverted:

    contrib/libvhost-user/libvhost-user-glib.h
    contrib/libvhost-user/libvhost-user.c
    contrib/libvhost-user/libvhost-user.h
    linux-user/mips64/cpu_loop.c
    linux-user/mips64/signal.c
    linux-user/sparc64/cpu_loop.c
    linux-user/sparc64/signal.c
    linux-user/x86_64/cpu_loop.c
    linux-user/x86_64/signal.c
    target/s390x/gen-features.c
    tests/migration/s390x/a-b-bios.c
    tests/test-rcu-simpleq.c
    tests/test-rcu-tailq.c

Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20181204172535.2799-1-armbru@redhat.com>
Acked-by: Eduardo Habkost <ehabkost@redhat.com>
Acked-by: Halil Pasic <pasic@linux.ibm.com>
Acked-by: Yuval Shaia <yuval.shaia@oracle.com>
Acked-by: Viktor Prutyanov <viktor.prutyanov@phystech.edu>
3 years agohw: acpi: Export and share the ARM RSDP build
Samuel Ortiz [Mon, 17 Dec 2018 15:34:48 +0000 (16:34 +0100)] 
hw: acpi: Export and share the ARM RSDP build

Now that build_rsdp() supports building both legacy and current RSDP
tables, we can move it to a generic folder (hw/acpi) and have the i386
ACPI code reuse it in order to reduce code duplication.

Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Andrew Jones <drjones@redhat.com>
3 years agohw: arm: Support both legacy and current RSDP build
Samuel Ortiz [Mon, 17 Dec 2018 10:48:36 +0000 (11:48 +0100)] 
hw: arm: Support both legacy and current RSDP build

We add the ability to build legacy or current RSDP tables, based on the
AcpiRsdpData revision field passed to build_rsdp().
Although arm/virt only uses RSDP v2, adding that capability to
build_rsdp will allow us to share the RSDP build code between ARM and x86.

Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Andrew Jones <drjones@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
3 years agohw: arm: Convert the RSDP build to the buid_append_foo() API
Samuel Ortiz [Mon, 17 Dec 2018 10:48:35 +0000 (11:48 +0100)] 
hw: arm: Convert the RSDP build to the buid_append_foo() API

Instead of filling a mapped and packed C structure field in random order
and being careful about endianness and sizes, build_rsdp() now uses
build_append_int_noprefix() to compose RSDP table.

This makes reviewing and maintaining code easier as this is almost
matching 1:1 the ACPI spec itself.

Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Andrew Jones <drjones@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
3 years agohw: arm: Carry RSDP specific data through AcpiRsdpData
Samuel Ortiz [Mon, 17 Dec 2018 10:48:34 +0000 (11:48 +0100)] 
hw: arm: Carry RSDP specific data through AcpiRsdpData

That will allow us to generalize the ARM build_rsdp() routine to support
both legacy RSDP (The current i386 implementation) and extended RSDP
(The ARM implementation).

Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Andrew Jones <drjones@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
3 years agohw: i386: Use correct RSDT length for checksum
Igor Mammedov [Mon, 17 Dec 2018 10:48:33 +0000 (11:48 +0100)] 
hw: i386: Use correct RSDT length for checksum

AcpiRsdpDescriptor describes revision 2 RSDP table so using sizeof(*rsdp)
for checksum calculation isn't correct since we are adding extra 16 bytes.
But acpi_data_push() zeroes out table, so just by luck we are summing up
exta zeros which still yelds correct checksum.

Fix it up by explicitly stating table size instead of using
pointer arithmetics on stucture.

PS:
Extra 16 bytes are still wasted, but droping them will break migration
for machines older than 2.3 due to size mismatch, for 2.3 and older it's
not an issue since they are using resizable memory regions (a1666142d)
for ACPI blobs. So keep wasting memory to avoid breaking old machines.

Fixes: 72c194f7e (i386: ACPI table generation code from seabios)
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
3 years agohw: arm: acpi: Fix incorrect checksums in RSDP
Igor Mammedov [Mon, 17 Dec 2018 10:48:32 +0000 (11:48 +0100)] 
hw: arm: acpi: Fix incorrect checksums in RSDP

When RSDP table was introduced (d4bec5d87), we calculated only legacy
checksum, and that was incorrect as it
 - specified rev=2 and forgot about extended checksum.
 - legacy checksum calculated on full table instead of the 1st 20 bytes

Fix it by adding extended checksum calculation and using correct
size for legacy checksum.

While at it use explicit constants to specify sub/full tables
sizes instead of relying on AcpiRsdpDescriptor size and fields offsets.
The follow up commits will convert this table to build_append_int_noprefix() API,
will use constants anyway and remove unused AcpiRsdpDescriptor structure.

Based on "[PATCH v5 05/24] hw: acpi: Implement XSDT support for  RSDP"
by Samuel Ortiz, who did it right in his impl.

Fixes: d4bec5d87 ("hw/arm/virt-acpi-build: Generate RSDP table")
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
CC: Ard Biesheuvel <ard.biesheuvel@linaro.org>
CC: Shannon Zhao <shannon.zhaosl@gmail.com>
Reviewed-by: Andrew Jones <drjones@redhat.com>
Reviewed-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
3 years agohw: acpi: The RSDP build API can return void
Samuel Ortiz [Mon, 17 Dec 2018 10:48:31 +0000 (11:48 +0100)] 
hw: acpi: The RSDP build API can return void

For both x86 and ARM architectures, the internal RSDP build API can
return void as the current return value is unused.

Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Andrew Jones <drjones@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
3 years agointel_iommu: remove "x-" prefix for "aw-bits"
Peter Xu [Mon, 17 Dec 2018 07:31:13 +0000 (15:31 +0800)] 
intel_iommu: remove "x-" prefix for "aw-bits"

We're going to have 57bits aw-bits support sooner.  It's possibly time
to remove the "x-" prefix.

Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
3 years agointel_iommu: dma read/write draining support
Peter Xu [Mon, 17 Dec 2018 07:31:12 +0000 (15:31 +0800)] 
intel_iommu: dma read/write draining support

Support DMA read/write draining should be easy for existing VT-d
emulation since the emulation itself does not have any request queue
there so we don't need to do anything to flush the un-commited queue.
What we need to do is to declare the support.

These capabilities are required to pass Windows SVVP test program.  It
is verified that when with parameters "x-aw-bits=48,caching-mode=off"
we can pass the Windows SVVP test with this patch applied.  Otherwise
we'll fail with:

        IOMMU[0] - DWD (DMA write draining) not supported
        IOMMU[0] - DWD (DMA read draining) not supported
        Segment 0 has no DMA remapping capable IOMMU units

However since these bits are not declared support for QEMU<=3.1, we'll
need a compatibility bit for it and we turn this on by default only
for QEMU>=4.0.

Please refer to VT-d spec 6.5.4 for more information.

CC: Yu Wang <wyu@redhat.com>
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1654550
Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
3 years agointel_iommu: convert invalid traces into error reports
Peter Xu [Mon, 17 Dec 2018 07:31:11 +0000 (15:31 +0800)] 
intel_iommu: convert invalid traces into error reports

Report more *_invalid() tracepoints to error_report_once() so that we
can detect issues even without tracing enabled.  Drop those tracepoints.

Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>