aboutsummaryrefslogtreecommitdiff
path: root/hw/ppc
AgeCommit message (Collapse)Author
2019-09-12migration: register_savevm_live doesn't need devDr. David Alan Gilbert
Commit 78dd48df3 removed the last caller of register_savevm_live for an instantiable device (rather than a single system wide device); so trim out the parameter. Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20190822115433.12070-1-dgilbert@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2019-09-04Merge remote-tracking branch ↵Peter Maydell
'remotes/ehabkost/tags/machine-next-pull-request' into staging Machine + x86 queue, 2019-09-03 Bug fixes: * Fix die-id validation regression (Eduardo Habkost) * vmmouse: Properly reset state (Jan Kiszka) * hostmem-file: fix pmem file size check (Stefan Hajnoczi) * Keep query-hotpluggable-cpus output compatible with older QEMU if '-smp dies' is not set (Igor Mammedov) * migration: Do not re-read the clock on pre_save in case of paused guest (Maxiwell S. Garcia) Cleanups: * NUMA code cleanups (Tao Xu) * Remove stale externs from includes (Alex Bennée) Features: * qapi: report the default CPU type for each machine (Daniel P. Berrangé) # gpg: Signature made Tue 03 Sep 2019 21:57:37 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: migration: Do not re-read the clock on pre_save in case of paused guest x86: do not advertise die-id in query-hotpluggbale-cpus if '-smp dies' is not set i386/vmmouse: Properly reset state hostmem-file: fix pmem file size check qapi: report the default CPU type for each machine pc: Don't make die-id mandatory unless necessary pc: Improve error message when die-id is omitted pc: Fix error message on die-id validation numa: move numa global variable numa_info into MachineState numa: move numa global variable have_numa_distance into MachineState numa: move numa global variable nb_numa_nodes into MachineState hw/arm: simplify arm_load_dtb includes: remove stale [smp|max]_cpus externs Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-09-03numa: move numa global variable numa_info into MachineStateTao Xu
Move existing numa global numa_info (renamed as "nodes") into NumaState. Reviewed-by: Igor Mammedov <imammedo@redhat.com> Suggested-by: Igor Mammedov <imammedo@redhat.com> Suggested-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Tao Xu <tao3.xu@intel.com> Message-Id: <20190809065731.9097-5-tao3.xu@intel.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2019-09-03numa: move numa global variable nb_numa_nodes into MachineStateTao Xu
Add struct NumaState in MachineState and move existing numa global nb_numa_nodes(renamed as "num_nodes") into NumaState. And add variable numa_support into MachineClass to decide which submachines support NUMA. Reviewed-by: Igor Mammedov <imammedo@redhat.com> Suggested-by: Igor Mammedov <imammedo@redhat.com> Suggested-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Tao Xu <tao3.xu@intel.com> Message-Id: <20190809065731.9097-3-tao3.xu@intel.com> [ehabkost: include hw/boards.h again to fix build failures] Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2019-08-29spapr: Set compat mode in spapr_core_plug()Greg Kurz
A recent change in spapr_machine_reset() showed that resetting the compat mode in spapr_machine_reset() for the boot vCPU and in spapr_cpu_reset() for all other vCPUs was fragile. The fix was thus to reset the compat mode for all vCPUs in spapr_machine_reset(), but we still have to propagate it to hot-plugged CPUs. This is still performed from spapr_cpu_reset(), hence resulting in ppc_set_compat() being called twice for every vCPU at machine reset. Apart from wasting cycles, which isn't really an issue during machine reset, this seems to indicate that spapr_cpu_reset() isn't the best place to set the compat mode. A natural candidate for CPU-hotplug specific code is spapr_core_plug(). Also, it sits in the same file as spapr_machine_reset() : this makes it easier for someone who wants to know when the compat PVR is set. Call ppc_set_compat() from there. This doesn't need to be done for initial vCPUs since the compat PVR is 0 and spapr_machine_reset() sets the appropriate value later. No need to do this on manually added vCPUS on the destination QEMU during migration since the compat PVR is part of the migrated vCPU state. Both conditions can be checked with spapr_drc_hotplugged(). Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <156701285312.499757.7807417667750711711.stgit@bahia.lan> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-08-29spapr/pci: Convert types to QEMU coding styleGreg Kurz
The QEMU coding style requires: - to typedef structured types (HACKING) - to use CamelCase for types and structure names (CODING_STYLE) Do that for PCI and Nvlink2 code. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <156701644465.505236.2850655823182656869.stgit@bahia.lan> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-08-29spapr_pci: Advertise BAR reallocation capabilityAlexey Kardashevskiy
The pseries guests do not normally allocate PCI resources and rely on the system firmware doing so. Furthermore at least at some point in the past the pseries guests won't even allowed to change BARs, probably it is still the case for phyp. So since the initial commit we have [1] which prevents resource reallocation. This is not a problem until we want specific BAR alignments, for example, PAGE_SIZE==64k to make sure we can still map MMIO BARs directly. For the boot time devices we handle this in SLOF [2] but since QEMU's RTAS does not allocate BARs, the guest does this instead and does not align BARs even if Linux is given pci=resource_alignment=16@pci:0:0 as PCI_PROBE_ONLY makes Linux ignore alignment requests. ARM folks added a dial to control PCI_PROBE_ONLY via the device tree [3]. This makes use of the dial to advertise to the guest that we can handle BAR reassignments. This limits the change to the latest pseries machine to avoid old guests explosion. We do not remove the flag from [1] as pseries guests are still supported under phyp so having that removed may cause problems. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/platforms/pseries/setup.c?h=v5.1#n773 [2] https://git.qemu.org/?p=SLOF.git;a=blob;f=board-qemu/slof/pci-phb.fs;h=06729bcf77a0d4e900c527adcd9befe2a269f65d;hb=HEAD#l338 [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f81c11af Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Message-Id: <20190719043734.108462-1-aik@ozlabs.ru> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-08-29spapr: Use SHUTDOWN_CAUSE_SUBSYSTEM_RESET for CAS rebootsDavid Gibson
The sPAPR platform includes feature negotiation between the guest and platform. That sometimes requires reconfiguring the virtual hardware, and in some cases that is a complex enough process that we trigger a system reset to handle it. That interacts badly with -no-reboot - we trigger the reboot, -no-reboot means we exit and so the guest never gets to try again. Eventually we want to get rid of CAS reboots entirely, since they're odd and irritating for the user. But in the meantime we can fix the -no-reboot problem by using SHUTDOWN_CAUSE_SUBSYSTEM_RESET which ignores -no-reboot and seems to be designed for this sort of faux-reset for internal purposes only. Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-08-29powerpc/spapr: Add host threads parameter to ibm,get_system_parameterSuraj Jitindar Singh
The ibm,get_system_parameter rtas call is used by the guest to retrieve data relating to certain parameters of the system. The SPLPAR characteristics option (token 20) is used to determine characteristics of the environment in which the lpar will run. It may be useful for a guest to know the number of physical host threads present on the underlying system where it is being run. Add the characteristic "HostThrs" to the SPLPAR Characteristics ibm,get_system_parameter rtas call to expose this information to a guest. Add a n_host_threads property to the processor class which is then used to retrieve this information and define it for POWER8 and POWER9. Other processors will default to 0 and the charateristic won't be added. Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com> Message-Id: <20190827045751.22123-1-sjitindarsingh@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-08-29pseries: Fix compat_pvr on resetLaurent Vivier
If we a migrate P8 machine to a P9 machine, the migration fails on destination with: error while loading state for instance 0x1 of device 'cpu' load of migration failed: Operation not permitted This is caused because the compat_pvr field is only present for the first CPU. Originally, spapr_machine_reset() calls ppc_set_compat() to set the value max_compat_pvr for the first cpu and this was propagated to all CPUs by spapr_cpu_reset(). Now, as spapr_cpu_reset() is called before that, the value is not propagated to all CPUs and the migration fails. To fix that, propagate the new value to all CPUs in spapr_machine_reset(). Fixes: 25c9780d38d4 ("spapr: Reset CAS & IRQ subsystem after devices") Signed-off-by: Laurent Vivier <lvivier@redhat.com> Message-Id: <20190826090812.19080-1-lvivier@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-08-29spapr_pci: remove all child functions in function zero unplugDaniel Henrique Barboza
There is nothing wrong with how sPAPR handles multifunction PCI hot unplugs. The problem is that x86 does it simpler. Instead of removing each non-zero function and then removing function zero, x86 can remove any function of the slot to trigger the hot unplug. Libvirt will be directly impacted by this difference, in the (hopefully soon) PCI Multifunction hot plug/unplug support. For hot plugs, both x86 and sPAPR will operate the same way: a XML with all desired functions to be added, then consecutive hotplugs of all non-zero functions first, zero last. For hot unplugs, at least in the current state, a XML with the devices to be removed must also be provided because of how sPAPR operates - x86 does not need it - since any function unplug will unplug the whole PCIe slot. This difference puts extra strain in the management layer, which needs to either handle both archs differently in the unplug scenario or choose treat x86 like sPAPR, forcing x86 users to cope with sPAPR internals. This patch changes spapr_pci_unplug_request to handle the unplug of function zero differently. When removing function zero, instead of error-ing out if there are any remaining function DRCs which needs detaching, detach those. This has no effect in any existing scripts that are detaching the non-zero functions before function zero, and can be used by management as a shortcut to remove the whole PCI multifunction device without specifying each child function. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20190822195918.3307-1-danielhb413@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-08-29ppc/pnv: Introduce PowerNV machines with fixed CPU modelsCédric Le Goater
Make the current "powernv" machine an abstract type and derive from it new machines with specific CPU models: power8 and power9. The "powernv" machine is now an alias on the "powernv9" machine. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20190731141233.1340-2-clg@kaod.org> [dwg: Adjust pnv-xscom-test to cope with this change] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-08-29ppc/pnv: Generate phandle for the "interrupt-parent" propertyCédric Le Goater
Devices such as the BT or serial devices require a valid "interrupt-parent" phandle in the device tree and it is currently empty (0x0). It was not a problem until now but since OpenFirmare started using a recent libdft (>= 1.4.7), petitboot fails to boot the system image with error : dtc_resize: fdt_open_into returned FDT_ERR_BADMAGIC Provide a phandle for the LPC bus. Suggested-by: Greg Kurz <groug@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20190723090138.30623-1-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-08-29ppc/pnv: add more dummy XSCOM addresses for the P9 CAPPCédric Le Goater
Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20190718115420.19919-3-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-08-29ppc/pnv: Set default ram size to 1.75GBJoel Stanley
This makes the powernv machine easier for end users as the default initrd address (1.5GB) is now within RAM. This uses less than 2GB of RAM to ensure 32 bit Qemu still works. Signed-off-by: Joel Stanley <joel@jms.id.au> Message-Id: <20190821030945.473-1-joel@jms.id.au> [dwg: Fix comment style for checkpatch] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-08-22Merge remote-tracking branch 'remotes/armbru/tags/pull-monitor-2019-08-21' ↵Peter Maydell
into staging Monitor patches for 2019-08-21 # gpg: Signature made Wed 21 Aug 2019 16:35:07 BST # gpg: using RSA key 354BC8B3D7EB2A6B68674E5F3870B400EB918653 # gpg: issuer "armbru@redhat.com" # gpg: Good signature from "Markus Armbruster <armbru@redhat.com>" [full] # gpg: aka "Markus Armbruster <armbru@pond.sub.org>" [full] # Primary key fingerprint: 354B C8B3 D7EB 2A6B 6867 4E5F 3870 B400 EB91 8653 * remotes/armbru/tags/pull-monitor-2019-08-21: monitor/qmp: Update comment for commit 4eaca8de268 qdev: Collect HMP handlers command handlers in qdev-monitor.c qapi: Move query-target from misc.json to machine.json hw/core: Move cpu.c, cpu.h from qom/ to hw/core/ Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-08-21Merge remote-tracking branch ↵Peter Maydell
'remotes/vivier2/tags/trivial-branch-pull-request' into staging Various trivial fixes # gpg: Signature made Wed 21 Aug 2019 12:19:11 BST # gpg: using RSA key CD2F75DDC8E3A4DC2E4F5173F30C38BD3F2FBE3C # gpg: issuer "laurent@vivier.eu" # gpg: Good signature from "Laurent Vivier <lvivier@redhat.com>" [full] # gpg: aka "Laurent Vivier <laurent@vivier.eu>" [full] # gpg: aka "Laurent Vivier (Red Hat) <lvivier@redhat.com>" [full] # Primary key fingerprint: CD2F 75DD C8E3 A4DC 2E4F 5173 F30C 38BD 3F2F BE3C * remotes/vivier2/tags/trivial-branch-pull-request: hw/display: Compile various display devices as common object hw/display/sm501: Remove unused include spapr_events: Rewrite a fall through comment vl: Rewrite a fall through comment target/ppc: Rewrite a fall through comment hw/ipmi: Rewrite a fall through comment hw/dma/omap_dma: Move switch 'fall through' comment to correct place json: Move switch 'fall through' comment to correct place hw/net/e1000: Fix erroneous comment .gitignore: ignore some vhost-user* related files configure: fix sdl detection using sdl2-config configure: remove obsoleted $sparc_cpu variable misc: fix naming scheme of compatiblity arrays test: Use g_strndup instead of plain strndup Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-08-21hw/core: Move cpu.c, cpu.h from qom/ to hw/core/Markus Armbruster
Suggested-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190709152053.16670-2-armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> [Rebased onto merge commit 95a9457fd44; missed instances of qom/cpu.h in comments replaced]
2019-08-21spapr_events: Rewrite a fall through commentPhilippe Mathieu-Daudé
GCC9 is confused by this comment when building with CFLAG -Wimplicit-fallthrough=2: CC ppc64-softmmu/hw/ppc/spapr_rtc.o hw/ppc/spapr_events.c: In function ‘rtas_event_log_to_source’: hw/ppc/spapr_events.c:312:12: error: this statement may fall through [-Werror=implicit-fallthrough=] 312 | if (spapr_ovec_test(spapr->ov5_cas, OV5_HP_EVT)) { | ^ hw/ppc/spapr_events.c:317:5: note: here 317 | case RTAS_LOG_TYPE_EPOW: | ^~~~ cc1: all warnings being treated as errors Rewrite the comment using 'fall through' which is recognized by GCC and static analyzers. Reported-by: Stefan Weil <sw@weilnetz.de> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20190719131425.10835-8-philmd@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2019-08-21spapr/irq: Drop spapr_irq_msi_reset()Greg Kurz
PHBs already take care of clearing the MSIs from the bitmap during reset or unplug. No need to do this globally from the machine code. Rather add an assert to ensure that PHBs have acted as expected. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <156415228966.1064338.190189424190233355.stgit@bahia.lan> Reviewed-by: Cédric Le Goater <clg@kaod.org> [dwg: Fix crash in qtest case where spapr->irq_map can be NULL at the new assert()] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-08-21spapr/pci: Free MSIs during resetGreg Kurz
When the machine is reset, the MSI bitmap is cleared but the allocated MSIs are not freed. Some operating systems, such as AIX, can detect the previous configuration and assert. Empty the MSI cache, this performs the needed cleanup. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <156415228410.1064338.4486161194061636096.stgit@bahia.lan> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-08-21spapr/pci: Consolidate de-allocation of MSIsGreg Kurz
When freeing MSIs, we need to: - remove them from the machine's MSI bitmap - remove them from the IC backend - remove them from the PHB's MSI cache This is currently open coded in two places in rtas_ibm_change_msi(), and we're about to need this in spapr_phb_reset() as well. Instead of duplicating this code again, make it a destroy function for the PHB's MSI cache. Removing an MSI device from the cache will call the destroy function internally. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <156415227855.1064338.5657793835271464648.stgit@bahia.lan> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-08-21spapr: Implement ibm,suspend-meNicholas Piggin
This has been useful to modify and test the Linux pseries suspend code but it requires modification to the guest to call it (due to being gated by other unimplemented features). It is not otherwise used by Linux yet, but work is slowly progressing there. This allows a (lightly modified) guest kernel to suspend with `echo mem > /sys/power/state` and be resumed with system_wakeup monitor command. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Message-Id: <20190722061752.22114-2-npiggin@gmail.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-08-21spapr: initial implementation for H_TPM_COMM/spapr-tpm-proxyMichael Roth
This implements the H_TPM_COMM hypercall, which is used by an Ultravisor to pass TPM commands directly to the host's TPM device, or a TPM Resource Manager associated with the device. This also introduces a new virtual device, spapr-tpm-proxy, which is used to configure the host TPM path to be used to service requests sent by H_TPM_COMM hcalls, for example: -device spapr-tpm-proxy,id=tpmp0,host-path=/dev/tpmrm0 By default, no spapr-tpm-proxy will be created, and hcalls will return H_FUNCTION. The full specification for this hypercall can be found in docs/specs/ppc-spapr-uv-hcalls.txt Since SVM-related hcalls like H_TPM_COMM use a reserved range of 0xEF00-0xEF80, we introduce a separate hcall table here to handle them. Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com Message-Id: <20190717205842.17827-3-mdroth@linux.vnet.ibm.com> [dwg: Corrected #include for upstream change] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-08-21spapr: Implement H_JOINNicholas Piggin
This has been useful to modify and test the Linux pseries suspend code but it requires modification to the guest to call it (due to being gated by other unimplemented features). It is not otherwise used by Linux yet, but work is slowly progressing there. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Message-Id: <20190718034214.14948-5-npiggin@gmail.com> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-08-21spapr: Implement H_CONFERNicholas Piggin
This does not do directed yielding and is not quite as strict as PAPR specifies in terms of precise dispatch behaviour. This generally will mean suboptimal performance, rather than guest misbehaviour. Linux does not rely on exact dispatch behaviour. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Message-Id: <20190718034214.14948-4-npiggin@gmail.com> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-08-21spapr: Implement H_PRODNicholas Piggin
H_PROD is added, and H_CEDE is modified to test the prod bit according to PAPR. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Message-Id: <20190718034214.14948-3-npiggin@gmail.com> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-08-21spapr: Implement dispatch tracking for tcgNicholas Piggin
Implement cpu_exec_enter/exit on ppc which calls into new methods of the same name in PPCVirtualHypervisorClass. These are used by spapr to implement the splpar VPA dispatch counter initially. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Message-Id: <20190718034214.14948-2-npiggin@gmail.com> [dwg: Removed unnecessary CONFIG_USER_ONLY checks as suggested by gkurz] Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-08-21ppc: fix leak in h_client_architecture_supportShivaprasad G Bhat
Free all SpaprOptionVector local pointers after use. Signed-off-by: Shivaprasad G Bhat <sbhat@linux.ibm.com> Message-Id: <156335160761.82682.11912058325777251614.stgit@lep8c.aus.stglabs.ibm.com> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-08-21ppc: fix memory leak in spapr_dt_drc()Shivaprasad G Bhat
Leaking the drc_name while preparing the DT properties. Fixing that. Also, remove the const qualifier from spapr_drc_name(). Signed-off-by: Shivaprasad G Bhat <sbhat@linux.ibm.com> Message-Id: <156335159028.82682.5404622104535818162.stgit@lep8c.aus.stglabs.ibm.com> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-08-21ppc: fix memory leak in spapr_caps_add_propertiesShivaprasad G Bhat
Free the capability name string after setting the capability. Signed-off-by: Shivaprasad G Bhat <sbhat@linux.ibm.com> Message-Id: <156335156198.82682.8756968724044750843.stgit@lep8c.aus.stglabs.ibm.com> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-08-21migration: Do not re-read the clock on pre_save in case of paused guestMaxiwell S. Garcia
Re-read the timebase before migrate was ported from x86 commit: 6053a86fe7bd: kvmclock: reduce kvmclock difference on migration The clock move makes the guest knows about the paused time between the stop and migrate commands. This is an issue in an already-paused VM because some side effects, like process stalls, could happen after migration. So, this patch checks the runstate of guest in the pre_save handler and do not re-reads the timebase in case of paused state (cold migration). Signed-off-by: Maxiwell S. Garcia <maxiwell@linux.ibm.com> Message-Id: <20190711194702.26598-1-maxiwell@linux.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-08-21spapr_pci: Allow 2MiB and 16MiB IOMMU pagesizes by defaultDavid Gibson
We've had the qemu and kernel KVM infrastructure to handle larger TCE page sizes for a while, but forgot to update the defaults to actually allow them. This turns that change on. Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-08-21hw: add compat machines for 4.2Cornelia Huck
Add 4.2 machine types for arm/i440fx/q35/s390x/spapr. For i440fx and q35, unversioned cpu models are still translated to -v1, as 0788a56bd1ae ("i386: Make unversioned CPU models be aliases") states this should only transition to the latest cpu model version in 4.3 (or later). Signed-off-by: Cornelia Huck <cohuck@redhat.com> Message-Id: <20190724103524.20916-1-cohuck@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-08-21spapr_iommu: Fix xlate trace to print translated addressAlexey Kardashevskiy
Currently we basically print IO address twice, fix this. Fixes: 7e472264e9e2 ("PPC: spapr: iommu: rework traces") Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Message-Id: <20190812054202.125492-1-aik@ozlabs.ru> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-08-21spapr: quantify error messages regarding capability settingsDaniel Black
Its not immediately obvious how cap-X=Y setting need to be applied to the command line so, for spapr capability error messages, this has been clarified to: appending -machine cap-X=Y The wrong value messages have been left as is, as the user has found the right location. Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: Daniel Black <daniel@linux.ibm.com> Message-Id: <20190812071044.30806-1-daniel@linux.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-08-16sysemu: Split sysemu/runstate.h off sysemu/sysemu.hMarkus Armbruster
sysemu/sysemu.h is a rather unfocused dumping ground for stuff related to the system-emulator. Evidence: * It's included widely: in my "build everything" tree, changing sysemu/sysemu.h still triggers a recompile of some 1100 out of 6600 objects (not counting tests and objects that don't depend on qemu/osdep.h, down from 5400 due to the previous two commits). * It pulls in more than a dozen additional headers. Split stuff related to run state management into its own header sysemu/runstate.h. Touching sysemu/sysemu.h now recompiles some 850 objects. qemu/uuid.h also drops from 1100 to 850, and qapi/qapi-types-run-state.h from 4400 to 4200. Touching new sysemu/runstate.h recompiles some 500 objects. Since I'm touching MAINTAINERS to add sysemu/runstate.h anyway, also add qemu/main-loop.h. Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190812052359.30071-30-armbru@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> [Unbreak OS-X build]
2019-08-16Clean up inclusion of sysemu/sysemu.hMarkus Armbruster
In my "build everything" tree, changing sysemu/sysemu.h triggers a recompile of some 5400 out of 6600 objects (not counting tests and objects that don't depend on qemu/osdep.h). Almost a third of its inclusions are actually superfluous. Delete them. Downgrade two more to qapi/qapi-types-run-state.h, and move one from char/serial.h to char/serial.c. hw/semihosting/config.c, monitor/monitor.c, qdev-monitor.c, and stubs/semihost.c define variables declared in sysemu/sysemu.h without including it. The compiler is cool with that, but include it anyway. This doesn't reduce actual use much, as it's still included into widely included headers. The next commit will tackle that. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20190812052359.30071-27-armbru@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
2019-08-16numa: Move remaining NUMA declarations from sysemu.h to numa.hMarkus Armbruster
Commit e35704ba9c "numa: Move NUMA declarations from sysemu.h to numa.h" left a few NUMA-related macros behind. Move them now. Cc: Eduardo Habkost <ehabkost@redhat.com> Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20190812052359.30071-26-armbru@redhat.com>
2019-08-16Include hw/boards.h a bit lessMarkus Armbruster
hw/boards.h pulls in almost 60 headers. The less we include it into headers, the better. As a first step, drop superfluous inclusions, and downgrade some more to what's actually needed. Gets rid of just one inclusion into a header. Cc: Eduardo Habkost <ehabkost@redhat.com> Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20190812052359.30071-23-armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
2019-08-16Include hw/qdev-properties.h lessMarkus Armbruster
In my "build everything" tree, changing hw/qdev-properties.h triggers a recompile of some 2700 out of 6600 objects (not counting tests and objects that don't depend on qemu/osdep.h). Many places including hw/qdev-properties.h (directly or via hw/qdev.h) actually need only hw/qdev-core.h. Include hw/qdev-core.h there instead. hw/qdev.h is actually pointless: all it does is include hw/qdev-core.h and hw/qdev-properties.h, which in turn includes hw/qdev-core.h. Replace the remaining uses of hw/qdev.h by hw/qdev-properties.h. While there, delete a few superfluous inclusions of hw/qdev-core.h. Touching hw/qdev-properties.h now recompiles some 1200 objects. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: "Daniel P. Berrangé" <berrange@redhat.com> Cc: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20190812052359.30071-22-armbru@redhat.com>
2019-08-16Include qemu/main-loop.h lessMarkus Armbruster
In my "build everything" tree, changing qemu/main-loop.h triggers a recompile of some 5600 out of 6600 objects (not counting tests and objects that don't depend on qemu/osdep.h). It includes block/aio.h, which in turn includes qemu/event_notifier.h, qemu/notify.h, qemu/processor.h, qemu/qsp.h, qemu/queue.h, qemu/thread-posix.h, qemu/thread.h, qemu/timer.h, and a few more. Include qemu/main-loop.h only where it's needed. Touching it now recompiles only some 1700 objects. For block/aio.h and qemu/event_notifier.h, these numbers drop from 5600 to 2800. For the others, they shrink only slightly. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190812052359.30071-21-armbru@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2019-08-16Include hw/hw.h exactly where neededMarkus Armbruster
In my "build everything" tree, changing hw/hw.h triggers a recompile of some 2600 out of 6600 objects (not counting tests and objects that don't depend on qemu/osdep.h). The previous commits have left only the declaration of hw_error() in hw/hw.h. This permits dropping most of its inclusions. Touching it now recompiles less than 200 objects. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20190812052359.30071-19-armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2019-08-16Include migration/vmstate.h lessMarkus Armbruster
In my "build everything" tree, changing migration/vmstate.h triggers a recompile of some 2700 out of 6600 objects (not counting tests and objects that don't depend on qemu/osdep.h). hw/hw.h supposedly includes it for convenience. Several other headers include it just to get VMStateDescription. The previous commit made that unnecessary. Include migration/vmstate.h only where it's still needed. Touching it now recompiles only some 1600 objects. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20190812052359.30071-16-armbru@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2019-08-16Include hw/irq.h a lot lessMarkus Armbruster
In my "build everything" tree, changing hw/irq.h triggers a recompile of some 5400 out of 6600 objects (not counting tests and objects that don't depend on qemu/osdep.h). hw/hw.h supposedly includes it for convenience. Several other headers include it just to get qemu_irq and.or qemu_irq_handler. Move the qemu_irq and qemu_irq_handler typedefs from hw/irq.h to qemu/typedefs.h, and then include hw/irq.h only where it's still needed. Touching it now recompiles only some 500 objects. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20190812052359.30071-13-armbru@redhat.com>
2019-08-16ide: Include hw/ide/internal a bit less outside hw/ide/Markus Armbruster
According to hw/ide/internal's file comment, only files in hw/ide/ are supposed to include it. Drag reality slightly closer to supposition. Three includes outside hw/ide remain: hw/arm/sbsa-ref.c, include/hw/ide/pci.h, and include/hw/misc/macio/macio.h. Turns out board code needs ide-internal.h to wire up IDE stuff. More cleanup is needed. Left for another day. Cc: John Snow <jsnow@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20190812052359.30071-11-armbru@redhat.com>
2019-08-16Include migration/qemu-file-types.h a lot lessMarkus Armbruster
In my "build everything" tree, changing migration/qemu-file-types.h triggers a recompile of some 2600 out of 6600 objects (not counting tests and objects that don't depend on qemu/osdep.h). The culprit is again hw/hw.h, which supposedly includes it for convenience. Include migration/qemu-file-types.h only where it's needed. Touching it now recompiles less than 200 objects. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190812052359.30071-10-armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2019-08-16Include sysemu/reset.h a lot lessMarkus Armbruster
In my "build everything" tree, changing sysemu/reset.h triggers a recompile of some 2600 out of 6600 objects (not counting tests and objects that don't depend on qemu/osdep.h). The main culprit is hw/hw.h, which supposedly includes it for convenience. Include sysemu/reset.h only where it's needed. Touching it now recompiles less than 200 objects. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20190812052359.30071-9-armbru@redhat.com>
2019-08-13spapr: Reset CAS & IRQ subsystem after devicesDavid Gibson
This fixes a nasty regression in qemu-4.1 for the 'pseries' machine, caused by the new "dual" interrupt controller model. Specifically, qemu can crash when used with KVM if a 'system_reset' is requested while there's active I/O in the guest. The problem is that in spapr_machine_reset() we: 1. Reset the CAS vector state spapr_ovec_cleanup(spapr->ov5_cas); 2. Reset all devices qemu_devices_reset() 3. Reset the irq subsystem spapr_irq_reset(); However (1) implicitly changes the interrupt delivery mode, because whether we're using XICS or XIVE depends on the CAS state. We don't properly initialize the new irq mode until (3) though - in particular setting up the KVM devices. During (2), we can temporarily drop the BQL allowing some irqs to be delivered which will go to an irq system that's not properly set up. Specifically, if the previous guest was in (KVM) XIVE mode, the CAS reset will put us back in XICS mode. kvm_kernel_irqchip() still returns true, because XIVE was using KVM, however XICs doesn't have its KVM components intialized and kernel_xics_fd == -1. When the irq is delivered it goes via ics_kvm_set_irq() which assert()s that kernel_xics_fd != -1. This change addresses the problem by delaying the CAS reset until after the devices reset. The device reset should quiesce all the devices so we won't get irqs delivered while we mess around with the IRQ. The CAS reset and irq re-initialize should also now be under the same BQL critical section so nothing else should be able to interrupt it either. We also move the spapr_irq_msi_reset() used in one of the legacy irq modes, since it logically makes sense at the same point as the spapr_irq_reset() (it's essentially an equivalent operation for older machine types). Since we don't need to switch between different interrupt controllers for those old machine types it shouldn't actually be broken in those cases though. Cc: Cédric Le Goater <clg@kaod.org> Fixes: b2e22477 "spapr: add a 'reset' method to the sPAPR IRQ backend" Fixes: 13db0cd9 "spapr: introduce a new sPAPR IRQ backend supporting XIVE and XICS" Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-07-28spapr/irq: Inform the user when falling back to emulated ICGreg Kurz
Just to give an indication to the user that the error condition is handled and how. Reported-by: Satheesh Rajendran <sathnaga@linux.vnet.ibm.com> Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <156398743479.546975.14566809803480887488.stgit@bahia.lan> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
generated by cgit v1.2.3 (git 2.26.2) at 2024-12-16 00:21:59 +0000