- 12 12月, 2018 1 次提交
-
-
由 Cornelia Huck 提交于
Reviewed-by: NDavid Hildenbrand <david@redhat.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
- 12 10月, 2018 1 次提交
-
-
由 Tony Krowiak 提交于
Introduces the base object model for virtualizing AP devices. Signed-off-by: NTony Krowiak <akrowiak@linux.ibm.com> Tested-by: NPierre Morel <pmorel@linux.ibm.com> Acked-by: NDavid Hildenbrand <david@redhat.com> Reviewed-by: NThomas Huth <thuth@redhat.com> Reviewed-by: NHalil Pasic <pasic@linux.ibm.com> Tested-by: NChristian Borntraeger <borntraeger@de.ibm.com> Message-Id: <20181010170309.12045-5-akrowiak@linux.ibm.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
- 04 10月, 2018 1 次提交
-
-
由 Janosch Frank 提交于
As the kernel has no way of disallowing the start of a huge page backed VM, we can migrate a running huge backed VM to a host that has no huge page KVM support. Let's glue huge page support support to the 3.1 machine, so we do not migrate to a destination host that doesn't have QEMU huge page support and can stop migration if KVM doesn't indicate support. Signed-off-by: NJanosch Frank <frankja@linux.ibm.com> Message-Id: <20180928093435.198573-1-frankja@linux.ibm.com> Reviewed-by: NDavid Hildenbrand <david@redhat.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
- 20 8月, 2018 2 次提交
-
-
由 Cornelia Huck 提交于
This option has been deprecated for two releases; remove it. Acked-by: NChristian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: NThomas Huth <thuth@redhat.com> Acked-by: NHalil Pasic <pasic@linux.ibm.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 Cornelia Huck 提交于
Reviewed-by: NDavid Hildenbrand <david@redhat.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
- 02 7月, 2018 2 次提交
-
-
由 David Hildenbrand 提交于
Let's treat this like a separate device. TCG will have to store the actual state/time later on. Include cpu-qom.h in kvm_s390x.h (due to S390CPU) to compile tod-kvm.c. Reviewed-by: NThomas Huth <thuth@redhat.com> Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20180627134410.4901-4-david@redhat.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 Christian Borntraeger 提交于
Most systems and host kernels provide the necessary building blocks for bpb and ppa15. We can reverse the logic and default enable those features, while still allowing to disable it via cpu model. So let us add bpb and ppa15 to z196 and later default CPU model for the qemu 3.0 machine. (like -cpu z13). Older machine types (e.g. s390-ccw-virtio-2.12) will retain the old value and not provide those bits in the default model. Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com> Message-Id: <20180626123830.18282-1-borntraeger@de.ibm.com> Reviewed-by: NDavid Hildenbrand <david@redhat.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
- 29 5月, 2018 1 次提交
-
-
由 Peter Maydell 提交于
Rename the 2.13 machines to match the number we're going to use for the next release. Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NCornelia Huck <cohuck@redhat.com> Reviewed-by: NThomas Huth <thuth@redhat.com> Message-id: 20180522104000.9044-4-peter.maydell@linaro.org
-
- 14 5月, 2018 1 次提交
-
-
由 David Hildenbrand 提交于
Calling pause_all_vcpus()/resume_all_vcpus() from a VCPU thread might not be the best idea. As pause_all_vcpus() temporarily drops the qemu mutex, two parallel calls to pause_all_vcpus() can be active at a time, resulting in a deadlock. (either by two VCPUs or by the main thread and a VCPU) Let's handle it via the main loop instead, as suggested by Paolo. If we would have two parallel reset requests by two different VCPUs at the same time, the last one would win. We use the existing ipl device to handle it. The nice side effect is that we can get rid of reipl_requested. This change implies that all reset handling now goes via the common path, so "no-reboot" handling is now active for all kinds of reboots. Let's execute any CPU initialization code on the target CPU using run_on_cpu. Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20180424101859.10239-1-david@redhat.com> Acked-by: NThomas Huth <thuth@redhat.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
- 11 5月, 2018 1 次提交
-
-
由 Igor Mammedov 提交于
Suggested-by: NEduardo Habkost <ehabkost@redhat.com> Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 1525691524-32265-5-git-send-email-imammedo@redhat.com Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
- 30 4月, 2018 2 次提交
-
-
由 Thomas Huth 提交于
The consoles ("sclpconsole" and "sclplmconsole") can only be configured with "-device" and "-chardev" so far. Other machines use the convenience option "-serial" to configure the default consoles, even for virtual consoles like spapr-vty on the pseries machine. So let's support this option on s390x, too. This way we can easily enable the serial console here again with "-nodefaults", for example: qemu-system-s390x -no-shutdown -nographic -nodefaults -serial mon:stdio ... which is way shorter than typing: qemu-system-s390x -no-shutdown -nographic -nodefaults \ -chardev stdio,id=c1,mux=on -device sclpconsole,chardev=c1 \ -mon chardev=c1 The -serial parameter can also be used if you only want to see the QEMU monitor on stdio without using -nodefaults, but not the console output. That's something that is pretty impossible with the current code today: qemu-system-s390x -no-shutdown -nographic -serial none While we're at it, this patch also maps the second -serial option to the "sclplmconsole", so that there is now an easy way to configure this second console on s390x, too, for example: qemu-system-s390x -no-shutdown -nographic -serial null -serial mon:stdio Additionally, the new code is also smaller than the old one and we have less s390x-specific code in vl.c :-) I've also checked that migration still works as expected by migrating a guest with console output back and forth between a qemu-system-s390x that has this patch and an instance without this patch. Signed-off-by: NThomas Huth <thuth@redhat.com> Message-Id: <1524754794-28005-1-git-send-email-thuth@redhat.com> Reviewed-by: NDavid Hildenbrand <david@redhat.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 Cornelia Huck 提交于
Reviewed-by: NThomas Huth <thuth@redhat.com> Reviewed-by: NDavid Hildenbrand <david@redhat.com> Acked-by: NChristian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
- 03 4月, 2018 1 次提交
-
-
由 Greg Kurz 提交于
The string returned by object_property_get_str() is dynamically allocated. Fixes: 3c4e9baaSigned-off-by: NGreg Kurz <groug@kaod.org> Message-Id: <152231460685.69730.14860451936216690693.stgit@bahia.lan> Reviewed-by: NCornelia Huck <cohuck@redhat.com> Reviewed-by: NThomas Huth <thuth@redhat.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
- 08 3月, 2018 3 次提交
-
-
由 Claudio Imbrenda 提交于
Until 67915de9 ("s390x/event-facility: variable-length event masks") we only supported sclp event masks with a size of exactly 4 bytes, even though the architecture allows the guests to set up sclp event masks from 1 to 1021 bytes in length. After that patch, the behaviour was almost compliant, but some issues were still remaining, in particular regarding the handling of selective reads and migration. When setting the sclp event mask, a mask size is also specified. Until now we only considered the size in order to decide which bits to save in the internal state. On the other hand, when a guest performs a selective read, it sends a mask, but it does not specify a size; the implied size is the size of the last mask that has been set. Specifying bits in the mask of selective read that are not available in the internal mask should return an error, and bits past the end of the mask should obviously be ignored. This can only be achieved by keeping track of the lenght of the mask. The mask length is thus now part of the internal state that needs to be migrated. This patch fixes the handling of selective reads, whose size will now match the length of the event mask, as per architecture. While the default behaviour is to be compliant with the architecture, when using older machine models the old broken behaviour is selected (allowing only masks of size exactly 4), in order to be able to migrate toward older versions. Fixes: 67915de9 ("s390x/event-facility: variable-length event masks") Signed-off-by: NClaudio Imbrenda <imbrenda@linux.vnet.ibm.com> Message-Id: <1519407778-23095-2-git-send-email-imbrenda@linux.vnet.ibm.com> Reviewed-by: NChristian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 David Hildenbrand 提交于
Right now it is possible to crash QEMU for s390x by providing e.g. -numa node,nodeid=0,cpus=0-1 Problem is, that numa.c uses mc->cpu_index_to_instance_props as an indicator whether NUMA is supported by a machine type. We don't implement NUMA for s390x ("topology") yet. However we need mc->cpu_index_to_instance_props for query-cpus. So let's fix this case by also checking for mc->get_default_cpu_node_id, which will be needed by machine_set_cpu_numa_node(). qemu-system-s390x: -numa node,nodeid=0,cpus=0-1: NUMA is not supported by this machine-type While at it, make s390_cpu_index_to_props() look like on other architectures. Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20180227110255.20999-1-david@redhat.com> Reviewed-by: NChristian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 Thomas Huth 提交于
The file name of the netboot binary is currently hard-coded to "s390-netboot.img", without a possibility for the user to select an alternative firmware image here. That's unfortunate, especially since the basics are already there: The filename is a property of the s390-ipl device. So we just have to add a check whether the user already provided the property and only set the default if the string is still empty. Now it is possible to select a different firmware image with "-global s390-ipl.netboot_fw=/path/to/s390-netboot.img". Signed-off-by: NThomas Huth <thuth@redhat.com> Message-Id: <1519731154-3127-1-git-send-email-thuth@redhat.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
- 26 2月, 2018 1 次提交
-
-
由 Viktor Mihajlovski 提交于
Presently s390x is the only architecture not exposing specific CPU information via QMP query-cpus. Upstream discussion has shown that it could make sense to report the architecture specific CPU state, e.g. to detect that a CPU has been stopped. With this change the output of query-cpus will look like this on s390: [ {"arch": "s390", "current": true, "props": {"core-id": 0}, "cpu-state": "operating", "CPU": 0, "qom_path": "/machine/unattached/device[0]", "halted": false, "thread_id": 63115}, {"arch": "s390", "current": false, "props": {"core-id": 1}, "cpu-state": "stopped", "CPU": 1, "qom_path": "/machine/unattached/device[1]", "halted": true, "thread_id": 63116} ] This change doesn't add the s390-specific data to HMP 'info cpus'. A follow-on patch will remove all architecture specific information from there. Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com> Reviewed-by: NDavid Hildenbrand <david@redhat.com> Reviewed-by: NChristian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: NEric Blake <eblake@redhat.com> Message-Id: <1518797321-28356-2-git-send-email-mihajlov@linux.vnet.ibm.com> Reviewed-by: NCornelia Huck <cohuck@redhat.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
- 09 2月, 2018 3 次提交
-
-
由 Markus Armbruster 提交于
qemu-common.h includes qemu/option.h, but most places that include the former don't actually need the latter. Drop the include, and add it to the places that actually need it. While there, drop superfluous includes of both headers, and separate #include from file comment with a blank line. This cleanup makes the number of objects depending on qemu/option.h drop from 4545 (out of 4743) to 284 in my "build everything" tree. Reviewed-by: NEric Blake <eblake@redhat.com> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Message-Id: <20180201111846.21846-20-armbru@redhat.com> [Semantic conflict with commit bdd6a90a in block/nvme.c resolved]
-
由 Markus Armbruster 提交于
Reviewed-by: NEric Blake <eblake@redhat.com> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Message-Id: <20180201111846.21846-6-armbru@redhat.com>
-
由 David Hildenbrand 提交于
We should be pretty good in shape now. Floating interrupts are working and atomic instructions should be atomic. Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20180129125623.21729-15-david@redhat.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
- 19 1月, 2018 1 次提交
-
-
由 Igor Mammedov 提交于
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: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NDavid Gibson <david@gibson.dropbear.id.au> Message-Id: <1515597770-268979-1-git-send-email-imammedo@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
- 15 12月, 2017 5 次提交
-
-
由 Christian Borntraeger 提交于
KVM does not allow memory regions > KVM_MEM_MAX_NR_PAGES, basically limiting the memory per slot to 8TB-4k. As memory slots on s390/kvm must be a multiple of 1MB we need start a new memory region if we cross 8TB-1M. With that (and optimistic overcommitment in the kernel) I was able to start a 24TB guest on a 1TB system. Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com> Message-Id: <20171211122146.162430-1-borntraeger@de.ibm.com> Reviewed-by: NDavid Hildenbrand <david@redhat.com> [CH: 1UL -> 1ULL in KVM_MEM_MAX_NR_PAGES; build fix on 32 bit hosts] Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 David Hildenbrand 提交于
We are good enough to boot upstream Linux kernels / Fedora 26/27. That should be sufficient for now. As the QEMU CPU model is migration safe, let's add compatibility code. Generate the feature list to reduce the chance of messing things up in the future. Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20171208165529.14124-1-david@redhat.com> [CH: squashed 's390x/cpumodel: make qemu cpu model play with "none" machine' (20171213132407.5227-1-david@redhat.com) and 's390x/tcg: don't include z13 features in the qemu model' (20171213171512.17601-1-david@redhat.com) into patch] Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 Halil Pasic 提交于
With the cssids unrestricted (commit "s390x/css: unrestrict cssids") the s390-squash-mcss machine property should not be used. Actually Libvirt never supported this, so the expectation is that removing it should be pretty painless. But let's play nice and deprecate it first. Signed-off-by: NHalil Pasic <pasic@linux.vnet.ibm.com> Message-Id: <20171206144438.28908-3-pasic@linux.vnet.ibm.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 Halil Pasic 提交于
The default css 0xfe is currently restricted to virtual subchannel devices. The hope when the decision was made was, that non-virtual subchannel devices will come around when guest can exploit multiple channel subsystems. Since the guests generally don't do, the pain of the partitioned (cssid) namespace outweighs the gain. Let us remove the corresponding restrictions (virtual devices can be put only in 0xfe and non-virtual devices in any css except the 0xfe -- while s390-squash-mcss then remaps everything to cssid 0). At the same time, change our schema for generating css bus ids to put both virtual and non-virtual devices into the default css (spilling over into other css images, if needed). The intention is to deprecate s390-squash-mcss. With this change devices without a specified devno won't end up hidden to guests not supporting multiple channel subsystems, unless this can not be avoided (default css full). Let us also advertise the changes to the management software (so it can tell are cssids unrestricted or restricted). The adverse effect of getting rid of the restriction on migration should not be too severe. Vfio-ccw devices are not live-migratable yet, and for virtual devices using the extra freedom would only make sense with the aforementioned guest support in place. The auto-generated bus ids are affected by both changes. We hope to not encounter any auto-generated bus ids in production as Libvirt is always explicit about the bus id. Since 8ed179c9 ("s390x/css: catch section mismatch on load", 2017-05-18) the worst that can happen because the same device ended up having a different bus id is a cleanly failed migration. I find it hard to reason about the impact of changed auto-generated bus ids on migration for command line users as I don't know which rules is such an user supposed to follow. Another pain-point is down- or upgrade of QEMU for command line users. The old way and the new way of doing vfio-ccw are mutually incompatible. Libvirt is only going to support the new way, so for libvirt users, the possible problems at QEMU downgrade are the following. If a domain contains virtual devices placed into a css different than 0xfe the domain will refuse to start with a QEMU not having this patch. Putting devices into a css different that 0xfe however won't make much sense in the near future (guest support). Libvirt will refuse to do vfio-ccw with a QEMU not having this patch. This is business as usual. Signed-off-by: NHalil Pasic <pasic@linux.vnet.ibm.com> Acked-by: NChristian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: NDong Jia Shi <bjsdjshi@linux.vnet.ibm.com> Message-Id: <20171206144438.28908-2-pasic@linux.vnet.ibm.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 Cornelia Huck 提交于
Acked-by: NChristian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: NDavid Hildenbrand <david@redhat.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
- 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>
-
- 20 10月, 2017 4 次提交
-
-
由 Igor Mammedov 提交于
s390-virtio-ccw.c is the sole user of s390x_new_cpu(), so move this helper there. Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Message-Id: <1508253203-119237-1-git-send-email-imammedo@redhat.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 David Hildenbrand 提交于
Nothing hindering us anymore from unlocking the restart code (used for NMI). Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20170928203708.9376-29-david@redhat.com> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 David Hildenbrand 提交于
This effectively enables experimental SMP support. Floating interrupts are still a mess, so allow it but print a big warning. There also seems to be a problem with CPU hotplug (after the main loop started). Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20170928203708.9376-27-david@redhat.com> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> [CH: changed insn-data.def as pointed out by Richard] Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 David Hildenbrand 提交于
We want to use the same code base for TCG, so let's cleanly factor it out. The sigp mutex is currently not really needed, as everything is protected by the iothread mutex. But this could change later, so leave it in place and initialize it properly from common code. Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20170928203708.9376-17-david@redhat.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
- 06 10月, 2017 6 次提交
-
-
由 Collin L. Walling 提交于
If we fail to set a proper TOD clock on the target system, this can already result in some problematic cases. We print several warn messages on source and target in that case. If kvm fails to set a nonzero epoch index, then we must ultimately fail the migration as this will result in a giant time leap backwards. This patch lets the migration fail if we can not set the guest time on the target. On failure the guest will resume normally on the original host machine. Signed-off-by: NCollin L. Walling <walling@linux.vnet.ibm.com> Reviewed-by: NEric Farman <farman@linux.vnet.ibm.com> Reviewed-by: NClaudio Imbrenda <imbrenda@linux.vnet.ibm.com> Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com> [split failure change from epoch index change, minor fixups] Message-Id: <20171004105751.24655-3-borntraeger@de.ibm.com> Reviewed-by: NThomas Huth <thuth@redhat.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 Halil Pasic 提交于
Commit e996583e ("s390x/css: activate ChannelSubSys migration", 2017-07-11) was supposed to enable css migration for virtio-ccw machines starting 2.10, but it ended up effectively enabling it only for 2.10 as the registration of the appropriate VMStateDescription happens in ccw_machine_2_10_instance_options which does not get called for machines more recent than 2_10. Let us move the corresponding chunk of code (which conditionally enables the migration based on the value of the corresponding class property) to ccw_init, which is called for each virtio-ccw machine instance. Signed-off-by: NHalil Pasic <pasic@linux.vnet.ibm.com> Reported-by: NThomas Huth <thuth@redhat.com> Message-Id: <20171004110109.16525-1-pasic@linux.vnet.ibm.com> Tested-by: NChristian Borntraeger <borntraeger@de.ibm.com> Acked-by: NChristian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 David Hildenbrand 提交于
Will be handy in the future. Reviewed-by: NThomas Huth <thuth@redhat.com> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20170928134609.16985-6-david@redhat.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 David Hildenbrand 提交于
Let's move it into the machine, so we trigger the IRQ after setting ms->possible_cpus (which SCLP uses to construct the list of online CPUs). This also fixes a problem reported by Thomas Huth, whereby qemu can be crashed using the none machine qemu-s390x-softmmu -M none -monitor stdio -> device_add qemu-s390-cpu Reviewed-by: NChristian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20170928134609.16985-3-david@redhat.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 Christian Borntraeger 提交于
This reverts commit d32bd032. Turns out that old QEMUs always created a pci host bridge and for many CPU models the migration from old QEMUs to new QEMUs will fail with qemu-system-s390x: Unknown savevm section or instance 'PCIBUS' 0 qemu-system-s390x: load of migration failed: Invalid argument As a quick fix we will revert the commit and always create the pci host bridge. Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com> [fixed revert to keep the comment fixup, added a comment in the code] Cc: Cornelia Huck <cohuck@redhat.com> Cc: David Hildenbrand <david@redhat.com> Message-Id: <20170928131831.81393-1-borntraeger@de.ibm.com> Reviewed-by: NDavid Hildenbrand <david@redhat.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 Igor Mammedov 提交于
Define default CPU type in generic way in machine class_init and let common machine code handle cpu_model parsing. Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <1505998749-269631-1-git-send-email-imammedo@redhat.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
- 20 9月, 2017 3 次提交
-
-
由 David Hildenbrand 提交于
Now that there is only one user of cpu_s390x_create() left, make cpu creation look like on x86. - Perform the model/properties split and checks in s390_init_cpus() - Parse features only once without having to remember if already parsed - Pass only the typename to s390x_new_cpu() - Use the typename of an existing CPU for hotplug via cpu-add Acked-by: NIgor Mammedov <imammedo@redhat.com> Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20170913132417.24384-21-david@redhat.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 David Hildenbrand 提交于
Now that we have possible_cpus, we can get rid of the global variable and rewrite s390_cpu_addr2state() to use it. Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20170913132417.24384-20-david@redhat.com> Reviewed-by: NIgor Mammedov <imammedo@redhat.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 David Hildenbrand 提交于
CPU hotplug is only possible on a per core basis on s390x. So let's add possible_cpus and wire everything up properly. Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20170913132417.24384-19-david@redhat.com> Acked-by: NIgor Mammedov <imammedo@redhat.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-