The PAPR interface defines a hypercall to pass high-quality
hardware generated random numbers to guests. Recent kernels can
already provide this hypercall to the guest if the right hardware
random number generator is available. But in case the user wants
to use another source like EGD, or QEMU is running with an older
kernel, we should also have this call in QEMU, so that guests that
do not support virtio-rng yet can get good random numbers, too.
This patch now adds a new pseudo-device to QEMU that either
directly provides this hypercall to the guest or is able to
enable the in-kernel hypercall if available. The in-kernel
hypercall can be enabled with the use-kvm property, e.g.:
qemu-system-ppc64 -device spapr-rng,use-kvm=true
For handling the hypercall in QEMU instead, a "RngBackend" is
required since the hypercall should provide "good" random data
instead of pseudo-random (like from a "simple" library function
like rand() or g_random_int()). Since there are multiple RngBackends
available, the user must select an appropriate back-end via the
"rng" property of the device, e.g.:
qemu-system-ppc64 -object rng-random,filename=/dev/hwrng,id=gid0 \
-device spapr-rng,rng=gid0 ...
See http://wiki.qemu-project.org/Features-Done/VirtIORNG for
other example of specifying RngBackends.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The buffer that is allocated in spapr_populate_drconf_memory()
is used for setting both, the "ibm,dynamic-memory" and the
"ibm,associativity-lookup-arrays" property. However, only the
size of the first one is taken into account when allocating the
memory. So if the length of the second property is larger than
the length of the first one, we run into a buffer overflow here!
Fix it by taking the length of the second property into account,
too.
Fixes: "spapr: Support ibm,dynamic-reconfiguration-memory" patch
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
At present, if guest numa nodes are requested, but the cpus in each node
are not specified, spapr just uses the default behaviour or assigning each
vcpu round-robin to nodes.
If smp_threads != 1, that will assign adjacent threads in a core to
different NUMA nodes. As well as being just weird, that's a configuration
that can't be represented in the device tree we give to the guest, which
means the guest and qemu end up with different ideas of the NUMA topology.
This patch implements mc->cpu_index_to_socket_id in the spapr code to
make sure vcpus get assigned to nodes only at the socket granularity.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Till now memory hotplug used RTAS_LOG_V6_HP_ID_DRC_INDEX hotplug type
which meant that we generated one hotplug type of EPOW event for every
256MB (SPAPR_MEMORY_BLOCK_SIZE). This quickly overruns the kernel
rtas log buffer thus resulting in loss of memory hotplug events. Switch
to RTAS_LOG_V6_HP_ID_DRC_COUNT hotplug type for memory so that we
generate only one event per hotplug request.
Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
Reviewed-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Support hotplug identifier type RTAS_LOG_V6_HP_ID_DRC_COUNT that allows
hotplugging of DRCs by specifying the DRC count.
While we are here, rename
spapr_hotplug_req_add_event() to spapr_hotplug_req_add_by_index()
spapr_hotplug_req_remove_event() to spapr_hotplug_req_remove_by_index()
so that they match with spapr_hotplug_req_add_by_count().
Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Don't represent non-hotluggable memory under drconf node. With this
we don't have to create DRC objects for them.
The effect of this patch is that we revert back to memory@XXXX representation
for all the memory specified with -m option and represent the cold
plugged memory and hot-pluggable memory under
ibm,dynamic-reconfiguration-memory.
Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
When NUMA isn't configured explicitly, assume node 0 is present for
the purpose of creating ibm,associativity-lookup-arrays property
under ibm,dynamic-reconfiguration-memory DT node. This ensures that
the associativity index property is correctly updated in ibm,dynamic-memory
for the LMB that is hotplugged.
Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Currently when user specifies more slots than allowed max of
SPAPR_MAX_RAM_SLOTS (32), we error out like this:
qemu-system-ppc64: unsupported amount of memory slots: 64
Let the user know about the max allowed slots like this:
qemu-system-ppc64: Specified number of memory slots 64 exceeds max supported 32
Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Currently PowerPC kernel doesn't allow hot-adding memory to memory-less
node, but instead will silently add the memory to the first node that has
some memory. This causes two unexpected behaviours for the user.
- Memory gets hotplugged to a different node than what the user specified.
- Since pc-dimm subsystem in QEMU still thinks that memory belongs to
memory-less node, a reboot will set things accordingly and the previously
hotplugged memory now ends in the right node. This appears as if some
memory moved from one node to another.
So until kernel starts supporting memory hotplug to memory-less
nodes, just prevent such attempts upfront in QEMU.
Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Make use of pc-dimm infrastructure to support memory hotplug
for PowerPC.
Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The hash table size is dependent on ram_size, but since with hotplug
the memory can grow till maxram_size. Hence make hash table size dependent
on maxram_size.
This allows to hotplug huge amounts of memory to the guest.
Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Parse ibm,architecture.vec table obtained from the guest and enable
memory node configuration via ibm,dynamic-reconfiguration-memory if guest
supports it. This is in preparation to support memory hotplug for
sPAPR guests.
This changes the way memory node configuration is done. Currently all
memory nodes are built upfront. But after this patch, only memory@0 node
for RMA is built upfront. Guest kernel boots with just that and rest of
the memory nodes (via memory@XXX or ibm,dynamic-reconfiguration-memory)
are built when guest does ibm,client-architecture-support call.
Note: This patch needs a SLOF enhancement which is already part of
SLOF binary in QEMU.
Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Enable memory hotplug for pseries 2.4 and add LMB DR connectors.
With memory hotplug, enforce RAM size, NUMA node memory size and maxmem
to be a multiple of SPAPR_MEMORY_BLOCK_SIZE (256M) since that's the
granularity in which LMBs are represented and hot-added.
LMB DR connectors will be used by the memory hotplug code.
Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
[spapr_drc_reset implementation]
[since this missed the 2.4 cutoff, changing to only enable for 2.5]
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
sPAPR uses hard coded limit of maximum 255 supported CPUs which is
exactly the same as QEMU-wide limit which is MAX_CPUMASK_BITS and also
defined as 255.
This makes use of a global CPU number limit for the "pseries" machine.
In order to anticipate future increase of the MAX_CPUMASK_BITS
(or to help debugging large systems), this also bumps the FDT_MAX_SIZE
limit from 256K to 1M assuming that 1 CPU core needs roughly 512 bytes
in the device tree so the new limit can cover up to 2048 CPU cores.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Initialize a hotplug memory region under which all the hotplugged
memory is accommodated. Also enable memory hotplug by setting
CONFIG_MEM_HOTPLUG.
Modelled on i386 memory hotplug.
Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
For setting debug watchpoints, sPAPR guests use H_SET_MODE hypercall.
The existing QEMU H_SET_MODE handler does not support this but
the KVM handler in HV KVM does. However it is not enabled.
This enables the in-kernel H_SET_MODE handler which handles:
- Completed Instruction Address Breakpoint Register
- Watch point 0 registers.
The rest is still handled in QEMU.
Reported-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The device tree presented to pseries machine type guests includes an
ibm,chip-id property which gives essentially the socket number of each
vcpu core (individual vcpu threads don't get a node in the device
tree).
To calculate this, it uses a vcpus_per_socket variable computed as
(smp_cpus / #sockets). This is correct for the usual case where
smp_cpus == smp_threads * smp_cores * #sockets.
However, you can start QEMU with the number of cores and threads
mismatching the total number of vcpus (whether that _should_ be
permitted is a topic for another day). It's a bit hard to say what
the "real" number of vcpus per socket here is, but for most purposes
(smp_threads * smp_cores) will more meaningfully match how QEMU
behaves with respect to socket boundaries.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
dumpdtb (-machine dumpdtb=<file>) allows one to inspect the generated
device tree of machine types that generate device trees. This is
useful for a) seeing what's there b) debugging/testing device tree
generator patches. It can be used as follows
$QEMU_CMDLINE -machine dumpdtb=dtb
dtc -I dtb -O dts dtb
Signed-off-by: Andrew Jones <drjones@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
QEMU is MSI-X capable and makes it available via ibm,change-msi, so
we should indicate this by adding /rtas/ibm,change-msix-capable to the
device tree.
This is specificed by PAPR.
Signed-off-by: Sam Bobroff <sam.bobroff@au1.ibm.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
QEMU has a notion of the guest name, so if it's present we might as
well put that into the device tree as /ibm,partition-name.
This is specificed by PAPR.
Signed-off-by: Sam Bobroff <sam.bobroff@au1.ibm.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Add pseries-2.5 machine version.
Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
[Altered to merge before memory hotplug -- dwg]
[Altered to work with b9f072d01 -- dwg]
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Include an error message when migration fails due to mismatch in
htab_shift values at source and target. This should provide a bit more
verbose message in addition to the current migration failure message
that reads like:
qemu-system-ppc64: error while loading state for instance 0x0 of device 'spapr/htab'
After this patch, the failure message will look like this:
qemu-system-ppc64: htab_shift mismatch: source 29 target 24
qemu-system-ppc64: error while loading state for instance 0x0 of device 'spapr/htab'
Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Now all TYPE_MACHINE subclasses use MACHINE_TYPE_NAME to generate the
class name. So instead of requiring each subclass to set
MachineClass::name manually, we can now set it automatically at the
TYPE_MACHINE class_base_init() function.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Marcel Apfelbaum <marcel@redhat.com>
[AF/ehabkost: Updated for s390-ccw machines]
[AF: Cleanup of intermediate virt and vexpress name handling]
Signed-off-by: Andreas Färber <afaerber@suse.de>
Machine class names should use the "-machine" suffix to allow
class-name-based machine class lookup to work. Rename the the pseries
machine classes using the MACHINE_TYPE_NAME macro.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Some kernels program a 0 address for io regions. PCI 3.0 spec
section 6.2.5.1 doesn't seem to disallow this.
based on patch by Michael Roth <mdroth@linux.vnet.ibm.com>
Add pci_allow_0_addr in MachineClass to conditionally
allow addr 0 for pseries, as this can break other architectures.
This patch allows to hotplug PCI card in pseries machine, as the first
added card BAR0 is always set to 0 address.
This as a temporary hack, waiting to fix PCI memory priorities for more
machine types...
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
A few last minute PPC changes for 2.4:
- spapr: Update SLOF
- spapr: Fix a few bugs
- spapr: Preparation for hotplug
- spapr: Minor code cleanups
- linux-user: Add mftb handling
- kvm: Enable hugepage support with memory-backend-file
- mac99: Remove nonexistent interrupt pin (Mac OS 9 fix)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iQIcBAABAgAGBQJVm/TZAAoJECszeR4D/txg0rUP/R1C5IAuY0vM7LOYRbp1jFmn
EO6AZpJaXvT2xP0wUd/rqJct/O41vDVbEmnhpUAQwZcgsyw1UaKhRQbnCtY9PHD2
d7NZiBdv3AAbh8pLFadRjDJr/HrfuWVfjKKep5cM87/o3zjVreeIX8Hs77xHia6/
90n3hcDF4QL8qx6fxCMT4mGpTtbxw85IcK2wyIU45cZSN0VYaTjDwcYokeSKqgxV
pi7UjZSM5nZcn7VI1Uray4NkgXGs92Lorrbg08OFQt0AoXROJOk4V/LX3HkHfDbI
BYUgaOQNdBkytkB3fJCsTgl2Up82bVP/tghMyZOIyBAU4MslnAOW6HAMX2TtNswx
7itnIb7DQsVDE/U234Xzf5qoH5x4nB9xKh2qLHPKSpgLChs6lAW37Af3N+V03JVb
k/WX6i0n70a6kUqCxcMTnVSINWandU2jdJ/S8woIqs6XhfLk7hh0ucg+VhgoQxW7
QpeD69c25eVHeZDoMKR/ZTigJg/EQGuV9B9OSx6SyA9WMS4dImt1m0PBdaUlIAFT
759lMMwQIb5sQYghJ63tgrOI5PBneGnelM1zDWt2SCS0rbSjLWIWP47pHoNmnzzp
vIhJX5GgVuzf0NrbZPSR7/6NuKKU6UW5CTGh3vFgRib/CWIbEgCE3yWQfflZKy5q
Q2xBuAjyWnBoipzI4hlz
=+Uma
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/agraf/tags/signed-ppc-for-upstream' into staging
Patch queue for ppc - 2015-07-07
A few last minute PPC changes for 2.4:
- spapr: Update SLOF
- spapr: Fix a few bugs
- spapr: Preparation for hotplug
- spapr: Minor code cleanups
- linux-user: Add mftb handling
- kvm: Enable hugepage support with memory-backend-file
- mac99: Remove nonexistent interrupt pin (Mac OS 9 fix)
# gpg: Signature made Tue Jul 7 16:48:41 2015 BST using RSA key ID 03FEDC60
# gpg: Good signature from "Alexander Graf <agraf@suse.de>"
# gpg: aka "Alexander Graf <alex@csgraf.de>"
* remotes/agraf/tags/signed-ppc-for-upstream: (30 commits)
sPAPR: Clear stale MSIx table during EEH reset
sPAPR: Reenable EEH functionality on reboot
sPAPR: Don't enable EEH on emulated PCI devices
spapr-vty: Use TYPE_ definition instead of hardcoding
spapr_vty: lookup should only return valid VTY objects
spapr_pci: drop redundant args in spapr_[populate, create]_pci_child_dt
spapr_pci: populate ibm,loc-code
spapr_pci: enumerate and add PCI device tree
xics_kvm: Don't enable KVM_CAP_IRQ_XICS if already enabled
ppc: Update cpu_model in MachineState
spapr: Consolidate cpu init code into a routine
spapr: Reorganize CPU dt generation code
cpus: Add a macro to walk CPUs in reverse
spapr: Support ibm, lrdr-capacity device tree property
spapr: Consider max_cpus during xics initialization
Revert "hw/ppc/spapr_pci.c: Avoid functions not in glib 2.12 (g_hash_table_iter_*)"
spapr_iommu: translate sPAPRTCEAccess to IOMMUAccessFlags
spapr_iommu: drop erroneous check in h_put_tce_indirect()
spapr_pci: set device node unit address as hex
spapr_pci: encode class code including Prog IF register
...
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Keep cpu_model field in MachineState uptodate so that it can be used
from the CPU hotplug path.
Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Alexander Graf <agraf@suse.de>
Factor out bits of sPAPR specific CPU initialization code into
a separate routine so that it can be called from CPU hotplug
path too.
Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Alexander Graf <agraf@suse.de>
Reorganize CPU device tree generation code so that it be reused from
hotplug path. CPU dt entries are now generated from spapr_finalize_fdt()
instead of spapr_create_fdt_skel().
Note: This is how the split-up looks like now:
Boot path
---------
spapr_finalize_fdt
spapr_populate_cpus_dt_node
spapr_populate_cpu_dt
spapr_fixup_cpu_numa_dt
spapr_fixup_cpu_smt_dt
ibm,cas path
------------
spapr_h_cas_compose_response
spapr_fixup_cpu_dt
spapr_fixup_cpu_numa_dt
spapr_fixup_cpu_smt_dt
Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Alexander Graf <agraf@suse.de>
Use max_cpus instead of smp_cpus when intializating xics system. Also
report max_cpus in ibm,interrupt-server-ranges device tree property of
interrupt controller node.
Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Alexander Graf <agraf@suse.de>
Currently although we have an sPAPRMachineState descended from MachineState
we don't have an sPAPRMAchineClass descended from MachineClass. So far it
hasn't been needed, but several upcoming features are going to want it,
so this patch creates a stub implementation.
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Alexander Graf <agraf@suse.de>
The sPAPRMachineState structure includes an entry_point field containing
the initial PC value for starting the machine, even though this always has
the value 0x100.
I think this is a hangover from very early versions which bypassed the
firmware when using -kernel. In any case it has no function now, so remove
it.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Alexander Graf <agraf@suse.de>
The ram_limit field was imported from sPAPREnvironment where it predates
the machine's ram size being available generically from machine->ram_size.
Worse, the existing code was inconsistent about where it got the ram size
from. Sometimes it used spapr->ram_limit, sometimes the global 'ram_size'
and sometimes a local 'ram_size' masking the global.
This cleans up the code to consistently use machine->ram_size, eliminating
spapr->ram_limit in the process.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Alexander Graf <agraf@suse.de>
The code for -machine pseries maintains a global sPAPREnvironment structure
which keeps track of general state information about the guest platform.
This predates the existence of the MachineState structure, but performs
basically the same function.
Now that we have the generic MachineState, fold sPAPREnvironment into
sPAPRMachineState, the pseries specific subclass of MachineState.
This is mostly a matter of search and replace, although a few places which
relied on the global spapr variable are changed to find the structure via
qdev_get_machine().
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Alexander Graf <agraf@suse.de>
XICS needs to know the upper value for cpu_index as it is used to compute
the number of servers:
smp_cpus * kvmppc_smt_threads() / smp_threads
When passing -smp cpus=1,threads=9 on a POWER8 host, we end up with:
1 * 8 / 9 = 0
... which leads to an assertion in both emulated:
Number of servers needs to be greater 0
Aborted (core dumped)
... and in-kernel XICS:
xics_kvm_realize: Assertion `icp->nr_servers' failed.
Aborted (core dumped)
With this patch, we are sure that nr_servers > 0. Passing the same bogus
-smp option then leads to:
qemu-system-ppc64: Cannot support more than 8 threads on PPC with KVM
... which is a lot more explicit than the XICS errors.
Signed-off-by: Greg Kurz <gkurz@linux.vnet.ibm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Alexander Graf <agraf@suse.de>
This section would be sent:
a- for all new machine types
b- for old machine types if section state is different form {running,paused}
that were the only giving us troubles.
So, in new qemus: it is alwasy there. In old qemus: they are only
there if it an error has happened, basically stoping on target.
Signed-off-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
I forgot to add compatibility for Power when adding section footers.
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Fixes: 37fb569c01
Signed-off-by: Juan Quintela <quintela@redhat.com>
qemu currently implements the hypercalls H_LOGICAL_CI_LOAD and
H_LOGICAL_CI_STORE as PAPR extensions. These are used by the SLOF firmware
for IO, because performing cache inhibited MMIO accesses with the MMU off
(real mode) is very awkward on POWER.
This approach breaks when SLOF needs to access IO devices implemented
within KVM instead of in qemu. The simplest example would be virtio-blk
using an iothread, because the iothread / dataplane mechanism relies on
an in-kernel implementation of the virtio queue notification MMIO.
To fix this, an in-kernel implementation of these hypercalls has been made,
(kernel commit 99342cf "kvmppc: Implement H_LOGICAL_CI_{LOAD,STORE} in KVM"
however, the hypercalls still need to be enabled from qemu. This performs
the necessary calls to do so.
It would be nice to provide some warning if we encounter a problematic
device with a kernel which doesn't support the new calls. Unfortunately,
I can't see a way to detect this case which won't either warn in far too
many cases that will probably work, or which is horribly invasive.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Alexander Graf <agraf@suse.de>
This option enables/disables PCI hotplug for a particular PHB.
Also add machine compatibility code to disable it by default for machine
types prior to pseries-2.4.
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
[agraf: move commas for compat fields]
Signed-off-by: Alexander Graf <agraf@suse.de>
We don't actually rely on this interface to surface hotplug events, and
instead rely on the similar-but-interrupt-driven check-exception RTAS
interface used for EPOW events. However, the existence of this interface
is needed to ensure guest kernels initialize the event-reporting
interfaces which will in turn be used by userspace tools to handle these
events, so we implement this interface here.
Since events surfaced by this call are mutually exclusive to those
surfaced via check-exception, we also update the RTAS event queue code
to accept a boolean to mark/filter for events accordingly.
Events of this sort are not currently generated by QEMU, but the interface
has been tested by surfacing hotplug events via event-scan in place
of check-exception.
Signed-off-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Alexander Graf <agraf@suse.de>
This extends the data structures currently used to report EPOW events to
guests via the check-exception RTAS interfaces to also include event types
for hotplug/unplug events.
This is currently undocumented and being finalized for inclusion in PAPR
specification, but we implement this here as an extension for guest
userspace tools to implement (existing guest kernels simply log these
events via a sysfs interface that's read by rtas_errd, and current
versions of rtas_errd/powerpc-utils already support the use of this
mechanism for initiating hotplug operations).
We also add support for queues of pending RTAS events, since in the
case of hotplug there's chance for multiple events being in-flight
at any point in time.
Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Alexander Graf <agraf@suse.de>
This interface is used to fetch an OF device-tree nodes that describes a
newly-attached device to guest. It is called multiple times to walk the
device-tree node and fetch individual properties into a 'workarea'/buffer
provided by the guest.
The device-tree is generated by QEMU and passed to an sPAPRDRConnector during
the initial hotplug operation, and the state of these RTAS calls is tracked by
the sPAPRDRConnector. When the last of these properties is successfully
fetched, we report as special return value to the guest and transition
the device to a 'configured' state on the QEMU/DRC side.
See docs/specs/ppc-spapr-hotplug.txt for a complete description of
this interface.
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Alexander Graf <agraf@suse.de>
hw_error() is designed for printing CPU-related error messages
(e.g. it also prints a full CPU register dump). For error messages
that are not directly related to CPU problems, a function like
error_report() should be used instead.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Alexander Graf <agraf@suse.de>
When specifying a non-existing file with the "-bios" parameter, QEMU
complained that it "could not find LPAR rtas". That's obviously a
copy-n-paste bug from the code which loads the spapr-rtas.bin, it
should complain about a missing firmware file instead.
Additionally the error message was printed with hw_error() - which
also dumps the whole CPU state. However, this does not make much
sense here since the CPU is not running yet and thus the registers
only contain zeroes. So let's use error_report() here instead.
And while we're at it, let's also bail out if the firmware file
had zero length.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Alexander Graf <agraf@suse.de>
Now that 2.4 development has opened, create a new pseries machine type
variant. For now it is identical to the pseries-2.3 machine type, but
a number of new features are coming that will need to set backwards
compatibility options.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Alexander Graf <agraf@suse.de>
Don't add the pseries-2.3 machine yet, but define the corresponding
SPAPR_COMPAT macro to make sure both pseries-2.2 and pseries-2.1 will
inherit HW_COMPAT_2_3.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
SPAPR_COMPAT_2_1 will need to include both HW_COMPAT_2_2 and
HW_COMPAT_2_1, so include HW_COMPAT_2_1 inside SPAPR_COMPAT_2_1 and
HW_COMPAT_2_2 inside SPAPR_COMPAT_2_2.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Changing the convention to include commas inside the macros will allow
macros containing empty lists to be defined and used without compilation
errors.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Changing the convention to include commas inside the macros will allow
macros containing empty lists to be defined and used without compilation
errors.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Memory hot-unplug support for pc, MSI-X
mapping update speedup for virtio-pci,
misc refactorings and bugfixes.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJVUFj/AAoJECgfDbjSjVRpteQH+gKoOMKilM6qvgdQS9vduFJ+
lDHNnmfgzWjVMEetiUOc9hImfEEyTyDFrkSI3wf4a8RZ7UnnDKD8hZR1nToySJPd
SuDP/EdtXYtInIMjc1MUUrJEP6qtjjgM+IbikVzHDxCeekrTMFz2w05MZ+V+hxI5
8b8ndPNfjX3ciIRjHKZ2u6hKEemhzxr1yyKTnJVGDN07hmfMbCyLsiWnFfShZwfv
g7USgiXjFfpvU5Q7QWpiCapfAaEpevRqieGzRjSbPy5Frm3XT7v+hWbFnvIJqUPj
5/SMV8I4qtKQe15Qah292HB//oaFM/AvRtHWvQkre3YIqFwyCYimQtjqoRCYC1E=
=x0ub
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging
pc, virtio enhancements
Memory hot-unplug support for pc, MSI-X
mapping update speedup for virtio-pci,
misc refactorings and bugfixes.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
# gpg: Signature made Mon May 11 08:23:43 2015 BST using RSA key ID D28D5469
# gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>"
# gpg: aka "Michael S. Tsirkin <mst@redhat.com>"
* remotes/mst/tags/for_upstream: (28 commits)
acpi: update expected files for memory unplug
virtio-scsi: Move DEFINE_VIRTIO_SCSI_FEATURES to virtio-scsi
virtio-net: Move DEFINE_VIRTIO_NET_FEATURES to virtio-net
pci: Merge pci_nic_init() into pci_nic_init_nofail()
acpi: add a missing backslash to the \_SB scope.
qmp-event: add event notification for memory hot unplug error
acpi: add hardware implementation for memory hot unplug
acpi: fix "Memory device control fields" register
acpi: extend aml_field() to support UpdateRule
acpi, mem-hotplug: add unplug cb for memory device
acpi, mem-hotplug: add unplug request cb for memory device
acpi, mem-hotplug: add acpi_memory_slot_status() to get MemStatus
docs: update documentation for memory hot unplug
virtio: coding style tweak
pci: remove hard-coded bar size in msix_init_exclusive_bar()
virtio-pci: speedup MSI-X masking and unmasking
virtio: introduce vector to virtqueues mapping
virtio-ccw: using VIRTIO_NO_VECTOR instead of 0 for invalid virtqueue
monitor: check return value of qemu_find_net_clients_except()
monitor: replace the magic number 255 with MAX_QUEUE_NUM
...
Conflicts:
hw/s390x/s390-virtio-bus.c
[PMM: fixed conflict in s390_virtio_scsi_properties and
s390_virtio_net_properties arrays; since the result of the
two conflicting patches is to empty the property arrays
completely, the conflict resolution is to remove them entirely.]
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
All of them were reported by codespell.
Most typos are in comments, one is in an error message.
Signed-off-by: Stefan Weil <sw@weilnetz.de>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
The following patches will limit the following things to legacy
machine type:
- maximum number of virtqueues for virtio-pci were limited to 64
Cc: Alexander Graf <agraf@suse.de>
Cc: qemu-ppc@nongnu.org
Signed-off-by: Jason Wang <jasowang@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Alexander Graf <agraf@suse.de>
This patches adds machine type specific instance initialization
functions. Those functions will be used by following patches to compat
class properties for legacy machine types.
Cc: Alexander Graf <agraf@suse.de>
Cc: qemu-ppc@nongnu.org
Signed-off-by: Jason Wang <jasowang@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Capture the explicit setting of "usb=no" into a separate bool, and
use it to skip the update of machine->usb in the board init function.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
On sPAPR we haven't supported boot once ever since it emerged, but
recently grew need for it. This patch implements boot once logic
to it.
While at it, we also move to the new bootdevice handling that got
introduced to the tree recently.
Reported-by: Dinar Valeev <dvaleev@suse.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
This fixes potential runtime crashes and two warnings from Coverity.
The new error message does not add a prefix "qemu:" because that is
already done in function hw_error. It also starts with an uppercase
letter because that seems to be the mostly used form.
Signed-off-by: Stefan Weil <sw@weilnetz.de>
[agraf: fix typo]
Signed-off-by: Alexander Graf <agraf@suse.de>
Running
x86_64-softmmu/qemu-system-x86_64 -machine pc,kernel_irqchip=on -enable-kvm
leads to crash:
qemu-system-x86_64: qemu/util/qemu-option.c:387: qemu_opt_get_bool_helper:
Assertion `opt->desc && opt->desc->type == QEMU_OPT_BOOL' failed. Aborted
(core dumped)
This happens because the commit e79d5a6 ("machine: remove qemu_machine_opts
global list") removed the global option descriptions and moved them to
MachineState's QOM properties.
Fix this by querying machine properties through designated wrappers.
Signed-off-by: Marcel Apfelbaum <marcel@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
We call try_create_xics() to create a "xics-kvm". If it fails, we
call it again to fall back to plain "xics".
try_create_xics() uses qdev_init(). qdev_init()'s error handling has
an unwanted side effect: it calls qerror_report_err(), which prints to
stderr. Looks like an error, but isn't.
In QMP context, it would stash the error in the monitor instead,
making the QMP command fail. Fortunately, it's only called from board
initialization, never in QMP context.
Clean up by cutting out the qdev_init() middle-man: set property
"realized" directly.
While there, improve the error message when we can't satisfy an
explicit user request for "xics-kvm", and exit(1) instead of abort().
Simplify the abort when we can't create "xics".
Signed-off-by: Markus Armbruster <armbru@redhat.com>
[agraf: squash in fix for uninitialized variable from mdroth]
Signed-off-by: Alexander Graf <agraf@suse.de>
On x86, the guest's RTC can be read with QMP, either from the RTC device's
"date" property or via the "rtc-time" property on the machine (which is an
alias to the former). This is set up in the mc146818rtc driver, and
doesn't work on other targets.
This patch adds a similar "date" property to the pseries machine's RTAS RTC
and adds a compatible alias to the machine.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Alexander Graf <agraf@suse.de>
The initial creation of the PAPR RTC qdev class left a wart - the rtc's
offset was left in the sPAPREnvironment structure, accessed via a global.
This patch moves it into the RTC device's own state structure, were it
belongs. This requires a small change to the migration stream format. In
order to handle incoming streams from older versions, we also need to
retain the rtc_offset field in the sPAPREnvironment structure, so that it
can be loaded into via the vmsd, then pushed into the RTC device.
Since we're changing the migration format, this also takes the opportunity
to:
* Change the rtc offset from a value in seconds to a value in
nanoseconds, allowing nanosecond offsets between host and guest
rtc time, if desired.
* Remove both the already unused "next_irq" field and now unused
"rtc_offset" field from the new version of the spapr migration
stream
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Alexander Graf <agraf@suse.de>
At present the PAPR RTC isn't a "device" as such - it's accessed only via
firmware/hypervisor calls, and is handled in the sPAPR core code. This
becomes inconvenient as we extend it in various ways.
This patch makes the PAPR RTC a separate device in the qemu device model.
For now, the only piece of device state - the rtc_offset - is still kept in
the global sPAPREnvironment structure. That's clearly wrong, but leaving
it to be fixed in a following patch makes for a clearer separation between
the internal re-organization of the device, and the behavioural changes
(because the migration stream format needs to change slightly when the
offset is moved into the device's own state).
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Alexander Graf <agraf@suse.de>
At the moment the RTAS (firmware/hypervisor) time of day functions are
implemented in spapr_rtas.c along with a bunch of other things. Since
we're going to be expanding these a bit, move the RTAS RTC related code
out into new file spapr_rtc.c. Also add its own initialization function,
spapr_rtc_init() called from the main machine init routine.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Alexander Graf <agraf@suse.de>
At the moment sPAPR only supports 512MB window for MMIO BARs. However
modern devices might want bigger 64bit BARs.
This extends MMIO window from 512MB to 62GB (aligned to
SPAPR_PCI_WINDOW_SPACING) and advertises it in 2 records in
the PHB "ranges" property. 32bit gets the space from
SPAPR_PCI_MEM_WIN_BUS_OFFSET till the end of 4GB, 64bit gets the rest
of the space. If no space is left, 64bit range is not advertised.
The MMIO space size is set to old value of 0x20000000 by default
for pseries machines older than 2.3.
The approach changes the device tree which is a guest visible change, however
it won't break migration as:
1. we do not support migration to older QEMU versions
2. migration to newer QEMU will migrate the device tree as well and since
the new layout only extends the old one and does not change address mappigns,
no breakage is expected here too.
SLOF change is required to utilize this extension.
Suggested-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Alexander Graf <agraf@suse.de>
The next patch will make MMIO space bigger and keep the old value for
older pseries machines.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Alexander Graf <agraf@suse.de>
Not all sysemu.h users need the NUMA declarations, and keeping them in a
separate file makes it easier to see what are the interfaces provided by
numa.c.
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
It's tempting, because usbdevice_create() is so simple to use. But
there's a lot of unwanted complexity behind the simple interface.
Switch to usb_create_simple().
Cc: Alexander Graf <agraf@suse.de>
Cc: qemu-ppc@nongnu.org
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
The argument is not longer used and the implementation
uses now QOM instead of QemuOpts.
Signed-off-by: Marcel Apfelbaum <marcel@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
Some ppc machines create a default usb controller based on a 'machine condition'.
Until now the logic was: create the usb controller if:
- the usb option was supplied in cli and value is true or
- the usb option was absent and both set_defaults and the machine
condition were true.
Modified the logic to:
Create the usb controller if:
- the machine condition is true and defaults are enabled or
- the usb option is supplied and true.
The main for this is to simplify the usb_enabled method.
Signed-off-by: Marcel Apfelbaum <marcel@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
The mingw32 compiler complains about trying to print variables of type
ssize_t with the %z format string specifier. Since we're printing it
as unsigned hex anyway, cast to size_t to silence the warning.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
If a TCG guest reboots during a running migration HTAB entries are not
marked dirty, and the destination boots with an invalid HTAB.
When a reboot occurs, explicitly mark the current HTAB dirty after
clearing it.
Signed-off-by: Samuel Mendoza-Jonas <sam.mj@au1.ibm.com>
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Alexander Graf <agraf@suse.de>
The n_valid and n_invalid fields are unsigned short integers but it is
possible to have more than 65535 entries in a contiguous hunk, overflowing
the field. This results in an incorrect HTAB being sent to the destination
during migration.
Signed-off-by: Samuel Mendoza-Jonas <sam.mj@au1.ibm.com>
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Alexander Graf <agraf@suse.de>
If a guest reboots during a running migration, changes to the
hash page table are not necessarily updated on the destination.
Opening a new file descriptor to the HTAB forces the migration
handler to resend the entire table.
Signed-off-by: Samuel Mendoza-Jonas <sam.mj@au1.ibm.com>
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Alexander Graf <agraf@suse.de>
QEMU has support for options per machine, keeping
a global list of options is no longer necessary.
Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com>
Reviewed-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Greg Bellows <greg.bellows@linaro.org>
Message-id: 1418217570-15517-2-git-send-email-marcel.a@redhat.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Now that we finally check for presence of dangling sysbus devices, make check
started complaining that the sPAPR PHB is one such device.
However, it really isn't. The spapr PHB is not really a traditional sysbus
device, but much more a special spapr pv device which is already able to get
created dynamically.
Move spapr to its own dynamic sysbus check handling and allow PHB devices to
get allocated dynamically.
Signed-off-by: Alexander Graf <agraf@suse.de>
As of qemu-2.1, spapr/pseries, has a set of versioned machine classes to
represent the machine type as it appeared to the guest in different qemu
versions. This allows for safe migration of guests between current and
future qemu versions.
However, these are organized a bit differently from those for PC: on PC,
the default plain "pc" machine type is just an alias for the most recent
versioned machine type. In sPAPR, it names the base machine class from
which the versioned types are derived.
The PC approach is preferable; it makes it clearer which explicit version
is the current one. Additionally updating the "current" machine as the
base class makes it even more likely than otherwise to incorrectly alter
the versioned machines' behaviour when updating the current machine.
Therefore this patch changes sPAPR to the PC approach - the base class
becomes abstract, and plain "pseries" becomes an alias for the most
recent versioned machine class. Since qemu-2.1 is now released, we also
create a new pseries-2.2 machine type, to incorporate changes during this
development cycle (for now it is identical to pseries-2.1).
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Alexander Graf <agraf@suse.de>
Current support for bus master (clearing OK bit) together with the need to
support guests which do not enable PCI bus mastering, leads to extra state in
VIRTIO_PCI_FLAG_BUS_MASTER_BUG bit, which isn't robust in case of cross-version
migration for the case when guests use the device before setting DRIVER_OK.
Rip out this code, and replace it:
- Modern QEMU doesn't need VIRTIO_PCI_FLAG_BUS_MASTER_BUG
so just drop it for latest machine type.
- For compat machine types, set PCI_COMMAND if DRIVER_OK
is set.
As this is needed for 2.1 for both pc and ppc, move PC_COMPAT macros from pc.h
to a new common header.
Cc: Greg Kurz <gkurz@linux.vnet.ibm.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Alexander Graf <agraf@suse.de>
Device models should access their block backends only through the
block-backend.h API. Convert them, and drop direct includes of
inappropriate headers.
Just four uses of BlockDriverState are left:
* The Xen paravirtual block device backend (xen_disk.c) opens images
itself when set up via xenbus, bypassing blockdev.c. I figure it
should go through qmp_blockdev_add() instead.
* Device model "usb-storage" prompts for keys. No other device model
does, and this one probably shouldn't do it, either.
* ide_issue_trim_cb() uses bdrv_aio_discard() instead of
blk_aio_discard() because it fishes its backend out of a BlockAIOCB,
which has only the BlockDriverState.
* PC87312State has an unused BlockDriverState[] member.
The next two commits take care of the latter two.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Max Reitz <mreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
The patch is big, but all it really does is replacing
dinfo->bdrv
by
blk_bs(blk_by_legacy_dinfo(dinfo))
The replacement is repetitive, but the conversion of device models to
BlockBackend is imminent, and will shorten it to just
blk_legacy_dinfo(dinfo).
Line wrapping muddies the waters a bit. I also omit tests whether
dinfo->bdrv is null, because it never is.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Benoît Canet <benoit.canet@nodalink.com>
Reviewed-by: Max Reitz <mreitz@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
dtc fails on a recent QEMU snapshot:
ERROR (name_properties): "name" property in /hypervisor#1 is incorrect ("hypervisor" instead of base node name)
Looking at the device tree we have a hypervisor property:
# lsprop hypervisor
hypervisor "kvm"
But we also have a hypervisor node, with a name that doesn't match:
# lsprop hypervisor#1/
name "hypervisor"
compatible "linux,kvm"
linux,phandle 7e5eb5d8 (2120136152)
Commit c08ce91d309c (spapr: add uuid/host details to device tree)
looks to have collided with an earlier patch. Remove the hypervisor
property.
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
On sPAPR, virtio devices are connected to the PCI bus and use MSI-X.
Commit cc943c36fa has modified MSI-X
so that writes are made using the bus master address space and follow
the IOMMU path.
Unfortunately, the IOMMU address space address space does not have an
MSI window: the notification is silently dropped in unassigned_mem_write
instead of reaching the guest... The most visible effect is that all
virtio devices are non-functional on sPAPR since then. :(
This patch does the following:
1) map the MSI window into the IOMMU address space for each PHB
- since each PHB instantiates its own IOMMU address space, we
can safely map the window at a fixed address (SPAPR_PCI_MSI_WINDOW)
- no real need to keep the MSI window setup in a separate function,
the spapr_pci_msi_init() code moves to spapr_phb_realize().
2) kill the global MSI window as it is not needed in the end
Signed-off-by: Greg Kurz <gkurz@linux.vnet.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
MAX_CPUS 256 is inconsistent with qemu supporting upto 255 cpus. This
MAX_CPUS number was percolated back to "virsh capabilities" with wrong
max_cpus.
Signed-off-by: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
We currently calculate the final RTAS and FDT location based on
the early estimate of the RMA size, cropped to 256M on KVM since
we only know the real RMA size at reset time which happens much
later in the boot process.
This means the FDT and RTAS end up right below 256M while they
could be much higher, using precious RMA space and limiting
what the OS bootloader can put there which has proved to be
a problem with some OSes (such as when using very large initrd's)
Fortunately, we do the actual copy of the device-tree into guest
memory much later, during reset, late enough to be able to do it
using the final RMA value, we just need to move the calculation
to the right place.
However, RTAS is still loaded too early, so we change the code to
load the tiny blob into qemu memory early on, and then copy it into
guest memory at reset time. It's small enough that the memory usage
doesn't matter.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
[aik: fixed errors from checkpatch.pl, defined RTAS_MAX_ADDR]
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
[agraf: fix compilation on 32bit hosts]
Signed-off-by: Alexander Graf <agraf@suse.de>
We want the associtivity lists of memory and CPU nodes to match but
memory nodes have incorrect domain#3 which is zero for CPU so they won't
match.
This clears domain#3 in the list to match CPUs associtivity lists.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Alexander Graf <agraf@suse.de>
In multiple places there is a node0_size variable calculation
which assumes that NUMA node #0 and memory node #0 are the same
things which they are not. Since we are going to change it and
do not want to change it in multiple places, let's make a helper.
This adds a spapr_node0_size() helper and makes use of it.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Alexander Graf <agraf@suse.de>
Linux kernel expects nodes to have power-of-two size and
does WARN_ON if this is not the case:
[ 0.041456] WARNING: at drivers/base/memory.c:115
which is:
===
/* Validate blk_sz is a power of 2 and not less than section size */
if ((block_sz & (block_sz - 1)) || (block_sz < MIN_MEMORY_BLOCK_SIZE)) {
WARN_ON(1);
block_sz = MIN_MEMORY_BLOCK_SIZE;
}
===
This splits memory nodes into set of smaller blocks with
a size which is a power of two. This makes sure the start
address of every node is aligned to the node size.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
[agraf: squash windows compile fix in]
Signed-off-by: Alexander Graf <agraf@suse.de>
Current QEMU does not support memoryless NUMA nodes, however
actual hardware may have them so it makes sense to have a way
to emulate them in QEMU. This prepares SPAPR for that.
This moves 2 calls of spapr_populate_memory_node() into
the existing loop over numa nodes so first several nodes may
have no memory and this still will work.
If there is no numa configuration, the code assumes there is just
a single node at 0 and it has all the guest memory.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Alexander Graf <agraf@suse.de>
This finishes refactoring by using the spapr_populate_memory_node helper
for all nodes and removing leftovers from spapr_populate_memory().
This is not a part of the previous patch because the patches look
nicer apart.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Alexander Graf <agraf@suse.de>
This moves recurring bits of code related to memory@xxx nodes
creation to a helper.
This makes use of the new helper for node@0.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Alexander Graf <agraf@suse.de>
Useful for identifying the guest/host uniquely within the
guest. Adding following properties to the guest root node.
vm,uuid - uuid of the guest
host-model - Host model number
host-serial - Host machine serial number
hypervisor type - Tells its "kvm"
Signed-off-by: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
PAPR compliant guest calls this in absence of kdump. This finally
reaches the guest and can be handled according to the policies set by
higher level tools(like taking dump) for further analysis by tools like
crash.
Linux kernel calls ibm,os-term when extended property of os-term is set.
This makes sure that a return to the linux kernel is gauranteed.
Signed-off-by: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
[agraf: reduce RTAS_TOKEN_MAX]
Signed-off-by: Alexander Graf <agraf@suse.de>
This implements an NMI interface POWERPC SPAPR machine.
This enables an "nmi" HMP/QMP command supported on SPAPR.
This calls POWERPC_EXCP_RESET (vector 0x100) in the guest to deliver NMI
to every CPU. The expected result is XMON (in-kernel debugger) invocation.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
0b183fc87 "memory: move mem_path handling to
memory_region_allocate_system_memory" disabled -mempath use for all
machines that do not use memory_region_allocate_system_memory() to
register RAM. Since SPAPR uses memory_region_init_ram(), the huge pages
support was disabled for it.
This replaces memory_region_init_ram()+vmstate_register_ram_global() with
memory_region_allocate_system_memory() to get huge pages back.
This changes RAM size from (ram_limit - rma_alloc_size) to ram_limit as
the previous patch moved RMA memory region allocation after RAM allocation
and therefore this change does not have immediate effect but simplifies
the code.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Alexander Graf <agraf@suse.de>
PPC970 does not support VRMA (virtual RMA) so real memory required
for SLOF to execute must be allocated by the KVM_ALLOCATE_RMA ioctl.
Later this memory is used as a part of the guest RAM area.
The RMA allocating code also registers a memory region for this piece
of RAM.
We are going to simplify memory regions layout: RMA memory region
will be a subregion in the RAM memory region, both starting from zero.
This way we will not have to take care of start address alignment for
the piece of RAM next to the RMA.
This moves memory region business closer to the RAM memory region
creation/allocation code.
As this is a mechanical patch, no change in behaviour is expected.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
[agraf: fix compilation on non-kvm systems]
Signed-off-by: Alexander Graf <agraf@suse.de>
During KVMPPC_H_CAS processing, the cpu-version updated value is stored
without taking care of the current endianess. As a consequence, the guest
may not switch to the right CPU model, leading to unexpected results.
If needed, the value is now converted.
Fixes: 6d9412ea81 ("target-ppc: Implement "compat" CPU option")
Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Reviewed-by: Greg Kurz <gkurz@linux.vnet.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
