| 5edb1b3f | 02-Mar-2018 |
Peter Maydell <peter.maydell@linaro.org> |
hw/core/split-irq: Device that splits IRQ lines
In some board or SoC models it is necessary to split a qemu_irq line so that one input can feed multiple outputs. We currently have qemu_irq_split()
hw/core/split-irq: Device that splits IRQ lines
In some board or SoC models it is necessary to split a qemu_irq line so that one input can feed multiple outputs. We currently have qemu_irq_split() for this, but that has several deficiencies: * it can only handle splitting a line into two * it unavoidably leaks memory, so it can't be used in a device that can be deleted
Implement a qdev device that encapsulates splitting of IRQs, with a configurable number of outputs. (This is in some ways the inverse of the TYPE_OR_IRQ device.)
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20180220180325.29818-13-peter.maydell@linaro.org
show more ...
|
| e80200c5 | 25-Oct-2017 |
Alexey Kardashevskiy <aik@ozlabs.ru> |
machine: Polish -machine xxx,help
The "-machine xxx,help" prints kernel-irqchip possible values as "OnOffSplit", this adds separators to the printed line.
Also, since only lower case letters are sp
machine: Polish -machine xxx,help
The "-machine xxx,help" prints kernel-irqchip possible values as "OnOffSplit", this adds separators to the printed line.
Also, since only lower case letters are specified in qapi/common.json, this changes the letter cases too.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
show more ...
|
| d342eb76 | 10-Jan-2018 |
Igor Mammedov <imammedo@redhat.com> |
possible_cpus: add CPUArchId::type field
Remove dependency of possible_cpus on 1st CPU instance, which decouples configuration data from CPU instances that are created using that data.
Also later i
possible_cpus: add CPUArchId::type field
Remove dependency of possible_cpus on 1st CPU instance, which decouples configuration data from CPU instances that are created using that data.
Also later it would be used for enabling early cpu to numa node configuration at runtime qmp_query_hotpluggable_cpus() should provide a list of available cpu slots at early stage, before machine_init() is called and the 1st cpu is created, so that mgmt might be able to call it and use output to set numa mapping.
Use MachineClass::possible_cpu_arch_ids() callback to set cpu type info, along with the rest of possible cpu properties, to let machine define which cpu type* will be used.
* for SPAPR it will be a spapr core type and for ARM/s390x/x86 a respective descendant of CPUClass.
Move parse_numa_opts() in vl.c after cpu_model is parsed into cpu_type so that possible_cpu_arch_ids() would know which cpu_type to use during layout initialization.
Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <1515597770-268979-1-git-send-email-imammedo@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
show more ...
|
| 03fcbd9d | 02-Nov-2017 |
Thomas Huth <thuth@redhat.com> |
qdev: Check for the availability of a hotplug controller before adding a device
The qdev_unplug() function contains a g_assert(hotplug_ctrl) statement, so QEMU crashes when the user tries to device_
qdev: Check for the availability of a hotplug controller before adding a device
The qdev_unplug() function contains a g_assert(hotplug_ctrl) statement, so QEMU crashes when the user tries to device_add + device_del a device that does not have a corresponding hotplug controller. This could be provoked for a couple of devices in the past (see commit 4c93950659487c7ad or 84ebd3e8c7d4fe955 for example), and can currently for example also be triggered like this:
$ s390x-softmmu/qemu-system-s390x -M none -nographic QEMU 2.10.50 monitor - type 'help' for more information (qemu) device_add qemu-s390x-cpu,id=x (qemu) device_del x ** ERROR:qemu/qdev-monitor.c:872:qdev_unplug: assertion failed: (hotplug_ctrl) Aborted (core dumped)
So devices clearly need a hotplug controller when they should be usable with device_add. The code in qdev_device_add() already checks whether the bus has a proper hotplug controller, but for devices that do not have a corresponding bus, there is no appropriate check available yet. In that case we should check whether the machine itself provides a suitable hotplug controller and refuse to plug the device if none is available.
Reviewed-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <1509617407-21191-3-git-send-email-thuth@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
show more ...
|