- 20 11月, 2017 1 次提交
-
-
由 Jason Wang 提交于
This reverts commit 5e89dc01 since: - we should use ID in the spec instead the one used by OEM - in the future, we should allow changing id through either property or EEPROM file. Cc: Stefan Weil <sw@weilnetz.de> Cc: Michael Nawrocki <michael.nawrocki@gtri.gatech.edu> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: NStefan Weil <sw@weilnetz.de> Signed-off-by: NJason Wang <jasowang@redhat.com>
-
- 16 11月, 2017 2 次提交
-
-
由 Dou Liyang 提交于
Linux and Windows need ACPI SRAT table to make memory hotplug work properly, however currently QEMU doesn't create SRAT table if numa options aren't present on CLI. Which breaks both linux and windows guests in certain conditions: * Windows: won't enable memory hotplug without SRAT table at all * Linux: if QEMU is started with initial memory all below 4Gb and no SRAT table present, guest kernel will use nommu DMA ops, which breaks 32bit hw drivers when memory is hotplugged and guest tries to use it with that drivers. Fix above issues by automatically creating a numa node when QEMU is started with memory hotplug enabled but without '-numa' options on CLI. (PS: auto-create numa node only for new machine types so not to break migration). Which would provide SRAT table to guests without explicit -numa options on CLI and would allow: * Windows: to enable memory hotplug * Linux: switch to SWIOTLB DMA ops, to bounce DMA transfers to 32bit allocated buffers that legacy drivers/hw can handle. [Rewritten by Igor] Reported-by: NThadeu Lima de Souza Cascardo <cascardo@canonical.com> Suggested-by: NIgor Mammedov <imammedo@redhat.com> Signed-off-by: NDou Liyang <douly.fnst@cn.fujitsu.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Richard Henderson <rth@twiddle.net> Cc: Eduardo Habkost <ehabkost@redhat.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: David Hildenbrand <david@redhat.com> Cc: Thomas Huth <thuth@redhat.com> Cc: Alistair Francis <alistair23@gmail.com> Cc: Takao Indoh <indou.takao@jp.fujitsu.com> Cc: Izumi Taku <izumi.taku@jp.fujitsu.com> Reviewed-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
由 Marcel Apfelbaum 提交于
Currently there is no MMIO range over 4G reserved for PCI hotplug. Since the 32bit PCI hole depends on the number of cold-plugged PCI devices and other factors, it is very possible is too small to hotplug PCI devices with large BARs. Fix it by reserving 2G for I4400FX chipset in order to comply with older Win32 Guest OSes and 32G for Q35 chipset. Even if the new defaults of pci-hole64-size will appear in "info qtree" also for older machines, the property was not implemented so no changes will be visible to guests. Note this is a regression since prev QEMU versions had some range reserved for 64bit PCI hotplug. Reviewed-by: NLaszlo Ersek <lersek@redhat.com> Reviewed-by: NGerd Hoffmann <kraxel@redhat.com> Signed-off-by: NMarcel Apfelbaum <marcel@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
- 14 11月, 2017 1 次提交
-
-
由 Greg Kurz 提交于
When using the emulated XICS, the 'info pic' monitor command shows: CPU 0 XIRR=ff000000 ((nil)) PP=ff MFRR=ff ICS 1000..13ff 0x10040060340 1000 MSI 05 00 1001 MSI 05 00 1002 MSI 05 00 1003 MSI ff 00 1004 LSI ff 00 1005 LSI ff 00 1006 LSI ff 00 1007 LSI ff 00 1008 MSI 05 00 1009 MSI 05 00 100a MSI 05 00 100b MSI 05 00 100c MSI 05 00 but when using the in-kernel XICS with the very same guest, we get: CPU 0 XIRR=00000000 ((nil)) PP=ff MFRR=ff ICS 1000..13ff 0x10032e00340 1000 MSI ff 00 1001 MSI ff 00 1002 MSI ff 00 1003 MSI ff 00 1004 LSI ff 00 1005 LSI ff 00 1006 LSI ff 00 1007 LSI ff 00 1008 MSI ff 00 1009 MSI ff 00 100a MSI ff 00 100b MSI ff 00 100c MSI ff 00 ie, all irqs are masked and XIRR is null, while we should get the same output as with the emulated XICS. If the guest is then migrated, 'info pic' shows the expected values on both source and destination. The problem is that QEMU doesn't synchronize with KVM before printing the XICS state. Migration happens to fix the output because it enforces synchronization with KVM. To fix the invalid output of 'info pic', this patch introduces a new synchronize_state operation for both ICPStateClass and ICSStateClass. The ICP operation relies on run_on_cpu() in order to kick the vCPU and avoid sleeping on KVM_GET_ONE_REG. Signed-off-by: NGreg Kurz <groug@kaod.org> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
- 13 11月, 2017 2 次提交
-
-
由 Emilio G. Cota 提交于
max_cpus needs to be an upper bound on the number of vCPUs initialized; otherwise TCG region initialization breaks. Some boards initialize a hard-coded number of vCPUs, which is not captured by the global max_cpus and therefore breaks TCG initialization. Fix it by adding the .min_cpus field to machine_class. This commit also changes some user-facing behaviour: we now die if -smp is below this hard-coded vCPU minimum instead of silently ignoring the passed -smp value (sometimes announcing this by printing a warning). However, the introduction of .default_cpus lessens the likelihood that users will notice this: if -smp isn't set, we now assign the value in .default_cpus to both smp_cpus and max_cpus. IOW, if a user does not set -smp, they always get a correct number of vCPUs. This change fixes 3468b59e ("tcg: enable multiple TCG contexts in softmmu", 2017-10-24), which broke TCG initialization for some ARM boards. Fixes: 3468b59eReported-by: NThomas Huth <thuth@redhat.com> Reviewed-by: NEduardo Habkost <ehabkost@redhat.com> Reviewed-by: NAlistair Francis <alistair.francis@xilinx.com> Signed-off-by: NEmilio G. Cota <cota@braap.org> Message-id: 1510343626-25861-6-git-send-email-cota@braap.org Suggested-by: NPeter Maydell <peter.maydell@linaro.org> Signed-off-by: NEmilio G. Cota <cota@braap.org> Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Mike Nawrocki 提交于
Adds a new PCI ID for the i82559a (0x8086 0x1030) interface. The "x-use-alt-device-id" property controls whether this new ID is to be used, and is true by default, and set to false in a compat entry. Signed-off-by: NMike Nawrocki <michael.nawrocki@gtri.gatech.edu> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NJason Wang <jasowang@redhat.com>
-
- 05 11月, 2017 1 次提交
-
-
由 Paolo Bonzini 提交于
Legacy PCI device assignment has been removed from Linux in 4.12, and had been deprecated 2 years ago there. We can remove it from QEMU as well. The ROM loading code was shared with Xen PCI passthrough, so move it to hw/xen. Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
- 01 11月, 2017 11 次提交
-
-
由 Mark Cave-Ayland 提交于
This is a legacy artifact from when the sun4m IOMMU implementation was the only IOMMU available within QEMU. Signed-off-by: NMark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
-
由 Mark Cave-Ayland 提交于
With the switch to the IOMMU memory region and DMA API, this is no longer required. Signed-off-by: NMark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
-
由 Mark Cave-Ayland 提交于
Signed-off-by: NMark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
-
由 Mark Cave-Ayland 提交于
This hack originated from before the memory region API was introduced, and increased the size of the ledma DMA device to capture incorrect accesses beyond the end of the ledma device. A full analysis can be found on Artyom's blog at http://tyom.blogspot.co.uk/2010/10/bug-in-all-solaris-versions-after-57.html. With the memory API we can now simply alias the incorrect access onto its intended destination allowing us to remove the hack. Signed-off-by: NMark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: NArtyom Tarasenko <atar4qemu@gmail.com> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Tested-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org>
-
由 Mark Cave-Ayland 提交于
Create a new SPARC32_DMA container object (including an appropriate container memory region) and add instances of the SPARC32_ESPDMA_DEVICE and SPARC32_LEDMA_DEVICE as child objects. The benefit is that most of the gpio wiring complexity between esp/espdma and lance/ledma is now hidden within the SPARC32_DMA realize function. Since the sun4m IOMMU is already QOMified we can find a reference to it using object_resolve_path_type() allowing us to completely remove all external references to the iommu pointer. Finally we rework sun4m's sparc32_dma_init() to invoke the new SPARC32_DMA object and wire up the remaining board memory regions/IRQs. Signed-off-by: NMark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: NArtyom Tarasenko <atar4qemu@gmail.com> Acked-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Tested-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org>
-
由 Mark Cave-Ayland 提交于
This makes it possible to reference the lance device from the ledma device as required. Signed-off-by: NMark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: NArtyom Tarasenko <atar4qemu@gmail.com> Acked-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Tested-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org>
-
由 Mark Cave-Ayland 提交于
This enables them to be used outside of lance.c. We also update the comment to refer to the SPARC32 lance device rather than the AMD PCNet-II device (of which lance is a register-compatible subset). Signed-off-by: NMark Cave-Ayland <mark.cave-ayland@ilande.co.uk> CC: Jason Wang <jasowang@redhat.com> Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Tested-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org>
-
由 Mark Cave-Ayland 提交于
This makes it possible to reference the esp device from the espdma device as required, and by wiring up the device ourselves in sun4m.c we can drop use of the esp_init() function. Signed-off-by: NMark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: NArtyom Tarasenko <atar4qemu@gmail.com> Acked-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Tested-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org>
-
由 Mark Cave-Ayland 提交于
This enables them to be used outside of esp.c. Signed-off-by: NMark Cave-Ayland <mark.cave-ayland@ilande.co.uk> CC: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: NArtyom Tarasenko <atar4qemu@gmail.com> Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Tested-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org>
-
由 Mark Cave-Ayland 提交于
This is in preparation to allow the type to be used elsewhere. Signed-off-by: NMark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: NArtyom Tarasenko <atar4qemu@gmail.com> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Tested-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org>
-
由 Mark Cave-Ayland 提交于
Signed-off-by: NMark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: NArtyom Tarasenko <atar4qemu@gmail.com> Acked-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Tested-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org>
-
- 30 10月, 2017 1 次提交
-
-
由 Christian Borntraeger 提交于
Starting a guest with <os> <type arch='s390x' machine='s390-ccw-virtio-2.9'>hvm</type> </os> <cpu mode='host-model'/> on an IBM z14 results in "qemu-system-s390x: Some features requested in the CPU model are not available in the configuration: gs" This is because guarded storage is fenced for compat machines that did not have guarded storage support. While this prevents future migration abort (by not starting the guest at all), not being able to start a "host-model" guest is very much unexpected. As it turns out, even if we would modify libvirt to not expand the cpu model to contain "gs" for compat machines, it cannot guarantee that a migration will succeed. For example if the kernel changes its features (or the user has nested=1 on one host but not on the other) the migration will fail nevertheless. So instead of fencing "gs" for machines <= 2.9 lets allow it for all machine types that support the CPU model. This will make "host-model" runnable all the time, while relying on the CPU model to reject invalid migration attempts. We also need to change the migration for guarded storage. Additional discussions about host-model are still pending but are out of scope of this patch. Suggested-by: NDavid Hildenbrand <david@redhat.com> Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com> Acked-by: NDavid Hildenbrand <david@redhat.com> Acked-by: NCornelia Huck <Cornelia Huck <cohuck@redhat.com> Acked-by: NHalil Pasic <pasic@linux.vnet.ibm.com>
-
- 27 10月, 2017 3 次提交
-
-
由 Igor Mammedov 提交于
Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Tested-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <1507211474-188400-37-git-send-email-imammedo@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Igor Mammedov 提交于
Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <1507211474-188400-33-git-send-email-imammedo@redhat.com> Reviewed-by: NArtyom Tarasenko <atar4qemu@gmail.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Juergen Gross 提交于
The Xen qdisk backend needs to test whether grant copy operations is available in the kernel. Unfortunately this collides with using xengnttab_set_max_grants() on some kernels as this operation has to be the first one after opening the gnttab device. In order to solve this problem test for the availability of grant copy in xen_be_init() opening the gnttab device just for that purpose and closing it again afterwards. Advertise the availability via a global flag and use that flag in the qdisk backend. Signed-off-by: NJuergen Gross <jgross@suse.com> Acked-by: NAnthony PERARD <anthony.perard@citrix.com> Signed-off-by: NStefano Stabellini <sstabellini@kernel.org>
-
- 20 10月, 2017 7 次提交
-
-
由 Halil Pasic 提交于
Simplify the error handling of the MSCH. Let the code detecting the condition tell (in a less ambiguous way) how it's to be handled. No changes in behavior. Signed-off-by: NHalil Pasic <pasic@linux.vnet.ibm.com> Message-Id: <20171017140453.51099-8-pasic@linux.vnet.ibm.com> [CH: fix return code for fctl != 0] Reviewed-by: NDong Jia Shi <bjsdjshi@linux.vnet.ibm.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 Halil Pasic 提交于
Simplify the error handling of the HSCH. Let the code detecting the condition tell (in a less ambiguous way) how it's to be handled. No changes in behavior. Signed-off-by: NHalil Pasic <pasic@linux.vnet.ibm.com> Message-Id: <20171017140453.51099-7-pasic@linux.vnet.ibm.com> Reviewed-by: NThomas Huth <thuth@redhat.com> Reviewed-by: NDong Jia Shi <bjsdjshi@linux.vnet.ibm.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 Halil Pasic 提交于
Simplify the error handling of the CSCH. Let the code detecting the condition tell (in a less ambiguous way) how it's to be handled. No changes in behavior. Signed-off-by: NHalil Pasic <pasic@linux.vnet.ibm.com> Message-Id: <20171017140453.51099-6-pasic@linux.vnet.ibm.com> Reviewed-by: NThomas Huth <thuth@redhat.com> Reviewed-by: NDong Jia Shi <bjsdjshi@linux.vnet.ibm.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 Halil Pasic 提交于
Simplify the error handling of the XSCH. Let the code detecting the condition tell (in a less ambiguous way) how it's to be handled. No changes in behavior. Signed-off-by: NHalil Pasic <pasic@linux.vnet.ibm.com> Message-Id: <20171017140453.51099-5-pasic@linux.vnet.ibm.com> Reviewed-by: NThomas Huth <thuth@redhat.com> Reviewed-by: NDong Jia Shi <bjsdjshi@linux.vnet.ibm.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 Halil Pasic 提交于
Simplify the error handling of the SSCH and RSCH handler avoiding arbitrary and cryptic error codes being used to tell how the instruction is supposed to end. Let the code detecting the condition tell how it's to be handled in a less ambiguous way. It's best to handle SSCH and RSCH in one go as the emulation of the two shares a lot of code. For passthrough this change isn't pure refactoring, but changes the way kernel reported EFAULT is handled. After clarifying the kernel interface we decided that EFAULT shall be mapped to unit exception. Same goes for unexpected error codes and absence of required ORB flags. Signed-off-by: NHalil Pasic <pasic@linux.vnet.ibm.com> Message-Id: <20171017140453.51099-4-pasic@linux.vnet.ibm.com> Tested-by: NDong Jia Shi <bjsdjshi@linux.vnet.ibm.com> [CH: cosmetic changes] Reviewed-by: NDong Jia Shi <bjsdjshi@linux.vnet.ibm.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 Halil Pasic 提交于
CSS code needs to tell the IO instruction handlers located in ioinst.c how the emulated instruction should be ended. Currently this is done by returning generic (POSIX) error codes, and mapping them to outcomes like condition codes. This makes bugs easy to create and hard to recognize. As a preparation for moving away from (mis)using generic error codes for flow control let us introduce a type which tells the instruction handler function how to end the instruction, in a more straight-forward and less ambiguous way. Signed-off-by: NHalil Pasic <pasic@linux.vnet.ibm.com> Message-Id: <20171017140453.51099-3-pasic@linux.vnet.ibm.com> Reviewed-by: NThomas Huth <thuth@redhat.com> Reviewed-by: NDong Jia Shi <bjsdjshi@linux.vnet.ibm.com> [CH: cosmetic changes] Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 Cornelia Huck 提交于
The architecture supports masks of variable length for sclp write event mask. We currently only support 4 byte event masks, as that is what Linux uses. Let's extend this to the maximum mask length supported by the architecture and return 0 to the guest for the mask bits we don't support in core. Initial patch by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: NCornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: NJason J. Herne <jjherne@linux.vnet.ibm.com> Message-Id: <1507729193-9747-1-git-send-email-jjherne@linux.vnet.ibm.com> Acked-by: NChristian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
- 18 10月, 2017 1 次提交
-
-
由 Michael Roth 提交于
device_unparent(dev, ...) is called when a device is unparented, either directly, or as a result of a parent device being finalized, and handles some final cleanup for the device. Part of this includes emiting a DEVICE_DELETED QMP event to notify management, which includes the device's path in the composition tree as provided by object_get_canonical_path(). object_get_canonical_path() assumes the device is still connected to the machine/root container, and will assert otherwise, but in some situations this isn't the case: If the parent is finalized as a result of object_unparent(), it will still be attached to the composition tree at the time any children are unparented as a result of that same call to object_unparent(). However, in some cases, object_unparent() will complete without finalizing the parent device, due to lingering references that won't be released till some time later. One such example is if the parent has MemoryRegion children (which take a ref on their parent), who in turn have AddressSpace's (which take a ref on their regions), since those AddressSpaces get cleaned up asynchronously by the RCU thread. In this case qdev:device_unparent() may be called for a child Device that no longer has a path to the root/machine container, causing object_get_canonical_path() to assert. Fix this by storing the canonical path during realize() so the information will still be available for device_unparent() in such cases. Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com> Signed-off-by: NGreg Kurz <groug@kaod.org> Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com> Tested-by: NEric Auger <eric.auger@redhat.com> Reviewed-by: NDavid Gibson <david@gibson.dropbear.id.au> Message-Id: <20171016222315.407-2-mdroth@linux.vnet.ibm.com> [Clear dev->canonical_path at the post_realize_fail label, which is cleaner. Suggested by David Gibson. - Paolo] Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
- 17 10月, 2017 10 次提交
-
-
由 Igor Mammedov 提交于
deduce core type directly from chip type instead of maintaining type mapping in PnvChipClass::cpu_model. Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Igor Mammedov 提交于
deduce cpu type directly from core type instead of maintaining type mapping in PnvCoreClass::cpu_oc and doing extra cpu_model parsing in pnv_core_class_init() Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Igor Mammedov 提交于
typically for cpus/core type names following convention is used new_type_prefix-superclass_typename make PNV core/chip to follow common convention. Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NCédric Le Goater <clg@kaod.org> Acked-by: NDavid Gibson <david@gibson.dropbear.id.au> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Igor Mammedov 提交于
use common cpu_model prasing in vl.c and set default cpu_model using generic MachineClass::default_cpu_type. Beside of switching to generic infrastructure it solves several issues. * ppc_cpu_class_by_name() is used to deal with lower/upper case and alias translations into actual cpu type, which fixes '-M powernv -cpu power8' and '-M powernv -cpu power9_v1.0' usecases which error out with: 'invalid CPU model 'FOO' for powernv machine' * allows to switch to lower-case typenames in pnv chip/core name (by convention typnames should be lower-case) * replace aliased names /power8, power9, .../ with exact cpu model names (i.e. typenames should be stable but aliases might decide to point to other cpu model withi family or changed by kvm). It will also help to simplify pnv_chip/core code and get rid of dependency on cpu_model parsing. Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NCédric Le Goater <clg@kaod.org> [dwg: Updated to make DD2.0 as default POWER9 chip] Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Igor Mammedov 提交于
use generic cpu_model parsing introduced by (6063d4c0 vl.c: convert cpu_model to cpu type and set of global properties before machine_init()) it allows to: * replace sPAPRMachineClass::tcg_default_cpu with MachineClass::default_cpu_type * drop cpu_parse_cpu_model() from hw/ppc/spapr.c and reuse one in vl.c * simplify spapr_get_cpu_core_type() by removing not needed anymore recurrsion since alias look up happens earlier at vl.c and spapr_get_cpu_core_type() works only with resulted from that cpu type. * spapr no more needs to parse/depend on being phased out MachineState::cpu_model, all tha parsing done by generic code and target specific callback. Signed-off-by: NIgor Mammedov <imammedo@redhat.com> [dwg: Correct minor compile error] Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Igor Mammedov 提交于
consolidate 'host' core type registration by moving it from KVM specific code into spapr_cpu_core.c, similar like it's done in x86 target. Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NGreg Kurz <groug@kaod.org> Acked-by: NDavid Gibson <david@gibson.dropbear.id.au> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Igor Mammedov 提交于
replace sPAPRCPUCoreClass::cpu_class with cpu type name since it were needed just to get that at points it were accessed. Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NGreg Kurz <groug@kaod.org> Acked-by: NDavid Gibson <david@gibson.dropbear.id.au> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Igor Mammedov 提交于
spapr core type definition doesn't have any fields that require it to be defined at runtime. So replace code that fills in TypeInfo at runtime with static TypeInfo array that does the same at complie time. Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NGreg Kurz <groug@kaod.org> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Igor Mammedov 提交于
there is a dedicated callback CPUClass::parse_features which purpose is to convert -cpu features into a set of global properties AND deal with compat/legacy features that couldn't be directly translated into CPU's properties. Create ppc variant of it (ppc_cpu_parse_featurestr) and move 'compat=val' handling from spapr_cpu_core.c into it. That removes a dependency of board/core code on cpu_model parsing and would let to reuse common -cpu parsing introduced by 6063d4c0 Set "max-cpu-compat" property only if it exists, in practice it should limit 'compat' hack to spapr machine and allow to avoid including machine/spapr headers in target/ppc/cpu.c Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Igor Mammedov 提交于
ppc_cpu_parse_features() is doing practically the same thing as generic cpu_parse_cpu_model(). So remove duplicated impl. and reuse generic one. Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NGreg Kurz <groug@kaod.org> Acked-by: NDavid Gibson <david@gibson.dropbear.id.au> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-