- 20 9月, 2017 8 次提交
-
-
由 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>
-
由 David Hildenbrand 提交于
device_del on a CPU will currently do nothing. Let's emit an error telling that this is will currently not work (there is no architecture support on s390x). Error message copied from ppc. (qemu) device_del cpu1 device_del cpu1 CPU hot unplug not supported on this machine Reviewed-by: NMatthew Rosato <mjrosato@linux.vnet.ibm.com> Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20170913132417.24384-18-david@redhat.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 David Hildenbrand 提交于
Some time ago we discussed that using "id" as property name is not the right thing to do, as it is a reserved property for other devices and will not work with device_add. Switch to the term "core-id" instead, and use it as an equivalent to "CPU address" mentioned in the PoP. There is no such thing as cpu number, so rename env.cpu_num to env.core_id. We use "core-id" as this is the common term to use for device_add later on (x86 and ppc). We can get rid of cpu->id now. Keep cpu_index and env->core_id in sync. cpu_index was already implicitly used by e.g. cpu_exists(), so keeping both in sync seems to be the right thing to do. cpu_index will now no longer automatically get set via cpu_exec_realizefn(). For now, we were lucky that both implicitly stayed in sync. Our new cpu property "core-id" can be a static property. Range checks can be avoided by using the correct type and the "setting after realized" check is done implicitly. device_add will later need the reserved "id" property. Hotplugging a CPU on s390x will then be: "device_add host-s390-cpu,id=cpu2,core-id=2". Reviewed-by: NMatthew Rosato <mjrosato@linux.vnet.ibm.com> Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20170913132417.24384-14-david@redhat.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 David Hildenbrand 提交于
Specifying more than 1 CPU (e.g. -smp 5) leads to SIGP errors (the guest tries to bring these CPUs up but fails), because we don't support multiple CPUs on s390x under TCG. Let's bail out if more than 1 is specified, so we don't raise people's hope. Tested-by: NMatthew Rosato <mjrosato@linux.vnet.ibm.com> Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20170913132417.24384-12-david@redhat.com> Reviewed-by: NIgor Mammedov <imammedo@redhat.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 David Hildenbrand 提交于
The only interface left, so let's properly rename it. Reviewed-by: NThomas Huth <thuth@redhat.com> Acked-by: NChristian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20170913132417.24384-5-david@redhat.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 David Hildenbrand 提交于
It is a leftover from the days where we had still the !ccw virtio machine. As this one is long gone, let's move everything to s390-virtio-ccw.c. Suggested-by: NCornelia Huck <cohuck@redhat.com> Reviewed-by: NThomas Huth <thuth@redhat.com> Acked-by: NChristian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20170913132417.24384-4-david@redhat.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
- 31 8月, 2017 6 次提交
-
-
由 David Hildenbrand 提交于
Let's just introduce an helper. Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Reviewed-by: NThomas Huth <thuth@redhat.com> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20170818114353.13455-17-david@redhat.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 David Hildenbrand 提交于
Let's avoid any KVM stuff in s390-virtio-ccw.c. This parameter is simply ignored. Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20170818114353.13455-6-david@redhat.com> Reviewed-by: NThomas Huth <thuth@redhat.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 David Hildenbrand 提交于
No need for kvm_enabled() as this function is only called from KVM and there is no reason why it shouldn't be allowed for tcg. It is simply not available under tcg. Also, there is no need to check for the machine type anymore. Just like ri_enabled(), we can directly use the stored flag, which results in "true" for the "none" machine. Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20170818114353.13455-5-david@redhat.com> Reviewed-by: NThomas Huth <thuth@redhat.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 David Hildenbrand 提交于
Only used in KVM and there is no reason why it shouldn't be allowed for tcg - it is simply not available. Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20170818114353.13455-4-david@redhat.com> Reviewed-by: NThomas Huth <thuth@redhat.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 Cornelia Huck 提交于
Don't create the s390 pci host bridge if we do not provide the zpci facility. Reviewed-by: NThomas Huth <thuth@redhat.com> Acked-by: NChristian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 Cornelia Huck 提交于
Reviewed-by: NDavid Hildenbrand <david@redhat.com> Reviewed-by: NHalil Pasic <pasic@linux.vnet.ibm.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
- 21 7月, 2017 1 次提交
-
-
由 Peter Maydell 提交于
On NetBSD, where tolower() and toupper() are implemented using an array lookup, the compiler warns if you pass a plain 'char' to these functions: gdbstub.c:914:13: warning: array subscript has type 'char' This reflects the fact that toupper() and tolower() give undefined behaviour if they are passed a value that isn't a valid 'unsigned char' or EOF. We have qemu_tolower() and qemu_toupper() to avoid this problem; use them. (The use in scsi-generic.c does not trigger the warning because it passes a uint8_t; we switch it anyway, for consistency.) Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NEric Blake <eblake@redhat.com> Reviewed-by: NRichard Henderson <rth@twiddle.net> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> for the s390 part. Acked-by: NDavid Gibson <david@gibson.dropbear.id.au> Message-id: 1500568290-7966-1-git-send-email-peter.maydell@linaro.org
-
- 14 7月, 2017 8 次提交
-
-
由 Fan Zhang 提交于
Introduce guarded storage support for KVM guests on s390. We need to enable the capability, extend machine check validity, sigp store-additional-status-at-address, and migration. The feature is fenced for older machine type versions. Signed-off-by: NFan Zhang <zhangfan@linux.vnet.ibm.com> Reviewed-by: NCornelia Huck <cohuck@redhat.com> Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
-
由 Jason J. Herne 提交于
Add esop and esop2 features to z12 model where esop2 was originally introduced. Disable esop and esop2 when using compatibility machine v2.9 or earlier. Signed-off-by: NJason J. Herne <jjherne@linux.vnet.ibm.com> Acked-by: NChristian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: NCornelia Huck <cohuck@redhat.com> Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
-
由 Yi Min Zhao 提交于
zPCI instructions and facilities are available since IBM zEnterprise EC12. To support z/PCI in QEMU we enable zpci, aen and ais facilities starting with zEC12 GA1. And we always set zpci and aen bits in max cpu model. Later they might be switched off due to applied real cpu model. For ais bit, we only provide it in the full cpu model beginning with zEC12 and defer its enablement in the default cpu model to a later point in time. At the same time, disable them for 2.9 and older machines. Because of introducing AIS facility, we could check if it's enabled to initialize flic->ais_supported with the real value. Signed-off-by: NYi Min Zhao <zyimin@linux.vnet.ibm.com> Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: NCornelia Huck <cohuck@redhat.com>
-
由 Yi Min Zhao 提交于
By initializing the CPU firstly, we are able to retrieve and use the CPU model features when initializing other subsystem or devices. Signed-off-by: NYi Min Zhao <zyimin@linux.vnet.ibm.com> Reviewed-by: NPierre Morel <pmorel@linux.vnet.ibm.com> Reviewed-by: NCornelia Huck <cohuck@redhat.com> Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
-
由 Halil Pasic 提交于
Turn on migration for the channel subsystem for the next machine. For legacy machines we still have to do things the old way. Signed-off-by: NHalil Pasic <pasic@linux.vnet.ibm.com> Reviewed-by: NCornelia Huck <cornelia.huck@de.ibm.com> Message-Id: <20170711145441.33925-6-pasic@linux.vnet.ibm.com> Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
-
由 Halil Pasic 提交于
Currently the migration of the channel subsystem (css) is only partial and is done by the virtio ccw proxies -- the only migratable css devices existing at the moment. With the current work on emulated and passthrough devices we need to decouple the migration of the channel subsystem state from virtio ccw, and have a separate section for it. A new section however necessarily breaks the migration compatibility. So let us introduce a switch at the machine class, and put it in 'off' state for now. We will turn the switch 'on' for future machines once all preparations are met. For compatibility machines the switch will stay 'off'. Signed-off-by: NHalil Pasic <pasic@linux.vnet.ibm.com> Acked-by: NCornelia Huck <cornelia.huck@de.ibm.com> Message-Id: <20170711145441.33925-3-pasic@linux.vnet.ibm.com> Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
-
由 Halil Pasic 提交于
We will need the machine class at machine initialization time, so the usual way via qdev won't do. Let's cache the machine class and also use the default values of the base machine for capability discovery. Signed-off-by: NHalil Pasic <pasic@linux.vnet.ibm.com> Acked-by: NCornelia Huck <cornelia.huck@de.ibm.com> Message-Id: <20170711145441.33925-2-pasic@linux.vnet.ibm.com> Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
-
由 Claudio Imbrenda 提交于
Storage attributes device, like we have for storage keys. Signed-off-by: NClaudio Imbrenda <imbrenda@linux.vnet.ibm.com> Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
-
- 13 6月, 2017 1 次提交
-
-
由 Juan Quintela 提交于
They are indpendent, and nowadays almost every device register things with qdev->vmsd. Signed-off-by: NJuan Quintela <quintela@redhat.com> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: NPeter Xu <peterx@redhat.com>
-
- 06 6月, 2017 1 次提交
-
-
由 Laurent Vivier 提交于
We can replace the four remaining calls of register_savevm() by calls to register_savevm_live(). So we can remove the function and as we don't allocate anymore the ops pointer with g_new0() we don't have to free it then. Signed-off-by: NLaurent Vivier <lvivier@redhat.com> Reviewed-by: NJuan Quintela <quintela@redhat.com> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
- 19 5月, 2017 2 次提交
-
-
由 Dong Jia Shi 提交于
The S390 virtual css support already has a mechanism to create a virtual subchannel and provide it to the guest. However, to pass-through subchannels to a guest, we need to introduce a new mechanism to create the subchannel according to the real device information. Thus we reconstruct css_create_virtual_sch to a new css_create_sch function to handle all these cases and do allocation and initialization of the subchannel according to the device type and machine configuration. Reviewed-by: NPierre Morel <pmorel@linux.vnet.ibm.com> Signed-off-by: NDong Jia Shi <bjsdjshi@linux.vnet.ibm.com> Message-Id: <20170517004813.58227-6-bjsdjshi@linux.vnet.ibm.com> Signed-off-by: NCornelia Huck <cornelia.huck@de.ibm.com>
-
由 Xiao Feng Ren 提交于
We want to support real (i.e. not virtual) channel devices even for guests that do not support MCSS-E (where guests may see devices from any channel subsystem image at once). As all virtio-ccw devices are in css 0xfe (and show up in the default css 0 for guests not activating MCSS-E), we need an option to squash both the virtio subchannels and e.g. passed-through subchannels from their real css (0-3, or 0 for hosts not activating MCSS-E) into the default css. This will be exploited in a later patch. Signed-off-by: NXiao Feng Ren <renxiaof@linux.vnet.ibm.com> Signed-off-by: NDong Jia Shi <bjsdjshi@linux.vnet.ibm.com> Message-Id: <20170517004813.58227-4-bjsdjshi@linux.vnet.ibm.com> Signed-off-by: NCornelia Huck <cornelia.huck@de.ibm.com>
-
- 02 5月, 2017 1 次提交
-
-
由 Farhan Ali 提交于
In order to specify the LOADPARM value one may now add ",loadparm=xxx" parameter to the "-machine s390-ccw-virtio" option. The property setter will normalize and check the value provided much like the way the HMC does. The value is stored, but not used at the moment. Initial patch from Eugene (jno) Dvurechenski. Signed-off-by: NEugene (jno) Dvurechenski <jno@linux.vnet.ibm.com> Signed-off-by: NFarhan Ali <alifm@linux.vnet.ibm.com> Reviewed-by: NChristian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: NCornelia Huck <cornelia.huck@de.ibm.com>
-
- 21 4月, 2017 2 次提交
-
-
由 Fei Li 提交于
Let's have a flic before we move on to initialize more specific subsystems that make use of it. Signed-off-by: NFei Li <sherrylf@linux.vnet.ibm.com> Reviewed-by: NCornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: NCornelia Huck <cornelia.huck@de.ibm.com>
-
由 Cornelia Huck 提交于
Signed-off-by: NCornelia Huck <cornelia.huck@de.ibm.com>
-
- 28 2月, 2017 1 次提交
-
-
由 Farhan Ali 提交于
Add new field to S390IPLState to store the name of the network boot loader. Signed-off-by: NFarhan Ali <alifm@linux.vnet.ibm.com> Reviewed-by: NChristian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: NCornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: NCornelia Huck <cornelia.huck@de.ibm.com> Reviewed-by: NThomas Huth <thuth@redhat.com>
-
- 24 2月, 2017 2 次提交
-
-
由 Halil Pasic 提交于
The maximal number of virtqueues per device can be limited on a per transport basis. For virtio-ccw this limit is defined by VIRTIO_CCW_QUEUE_MAX, however the limitation used to come form the number of adapter routes supported by flic (via notifiers). Recently the limitation of the flic was adjusted so that it can accommodate VIRTIO_QUEUE_MAX queues, and is in the meanwhile checked for separately too. Let us remove the transport specific limitation of virtio-ccw by dropping VIRTIO_CCW_QUEUE_MAX and using VIRTIO_QUEUE_MAX instead. Signed-off-by: NHalil Pasic <pasic@linux.vnet.ibm.com> Signed-off-by: NCornelia Huck <cornelia.huck@de.ibm.com>
-
由 Halil Pasic 提交于
Let's increase ADAPTER_ROUTES_MAX_GSI to VIRTIO_QUEUE_MAX which is the largest demand foreseeable at the moment. Let us add a compatibility macro for the previous machines so client code can maintain backwards migration compatibility To not mess up migration compatibility for virtio-ccw VIRTIO_CCW_QUEUE_MAX is left at it's current value, and will be dropped when virtio-ccw is converted to use the capability of the flic introduced by this patch. Signed-off-by: NHalil Pasic <pasic@linux.vnet.ibm.com> Signed-off-by: NCornelia Huck <cornelia.huck@de.ibm.com>
-
- 20 1月, 2017 2 次提交
-
-
由 Cornelia Huck 提交于
Signed-off-by: NCornelia Huck <cornelia.huck@de.ibm.com> Acked-by: NChristian Borntraeger <borntraeger@de.ibm.com>
-
由 Christian Borntraeger 提交于
We chain our compat handler via the CCW_COMPAT macros and via the class_init function. (e.g. ccw_machine_2_7_class_options calls ccw_machine_2_8_class_options). As all class_init functions in that chain call SET_MACHINE_COMPAT for their compat settings, and SET_MACHINE_COMPAT will append there is no need to do that again. Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: NCornelia Huck <cornelia.huck@de.ibm.com>
-
- 19 9月, 2016 1 次提交
-
-
由 Christian Borntraeger 提交于
cpu model was merged with 2.8, it is wrong to abuse ri_allowed which was enabled with 2.7. Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: NCornelia Huck <cornelia.huck@de.ibm.com>
-
- 06 9月, 2016 1 次提交
-
-
由 David Hildenbrand 提交于
To be able to query the correct host model for the "none" machine, let's allow runtime-instrumentation for that machine. Acked-by: NCornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: NDavid Hildenbrand <dahi@linux.vnet.ibm.com> Message-Id: <20160905085244.99980-21-dahi@linux.vnet.ibm.com> Signed-off-by: NCornelia Huck <cornelia.huck@de.ibm.com>
-
- 05 9月, 2016 1 次提交
-
-
由 Cornelia Huck 提交于
Signed-off-by: NCornelia Huck <cornelia.huck@de.ibm.com>
-
- 20 7月, 2016 1 次提交
-
-
由 Cornelia Huck 提交于
We need to implement the get_dev_path method for the css bus, or else we might end up with two different devices having the same qdev_path. This was noticed when adding two scsi_hd controllers: The SCSIBus code will produce a non-unique dev_path for vmstate usage if the parent bus does not provide the get_dev_path method. We simply use the device's bus id, as this is unique and we won't have any deeper hierarchy from a channel subsystem perspective anyway. Note that we need to disable this for older machine versions, as this changes the migration format. Reported-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com> Reviewed-by: NHalil Pasic <pasic@linux.vnet.ibm.com> Reviewed-by: NSascha Silbe <silbe@linux.vnet.ibm.com> Tested-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com> Signed-off-by: NCornelia Huck <cornelia.huck@de.ibm.com>
-
- 11 7月, 2016 1 次提交
-
-
由 Jing Liu 提交于
Currently, common base layers virtual css bridge and bus are defined in hw/s390x/virtio-ccw.c(h). In order to support multiple types of devices in the virtual channel subsystem, especially non virtio-ccw, refactoring work needs to be done. This work is just a pure code move without any functional change except dropping an empty function virtual_css_bridge_init() and virtio_ccw_busdev_unplug() changing. virtio_ccw_busdev_unplug() is specific to virtio-ccw but gets referenced from the common virtual css bridge code. To keep the functional changes to a minimum we export this function from virtio-ccw.c and continue to reference it inside virtual_css_bridge_class_init() (now living in hw/s390x/css-bridge.c). A follow-up patch will clean this up. Signed-off-by: NJing Liu <liujbjl@linux.vnet.ibm.com> Reviewed-by: NSascha Silbe <silbe@linux.vnet.ibm.com> Reviewed-by: NDong Jia Shi <bjsdjshi@linux.vnet.ibm.com> Signed-off-by: NCornelia Huck <cornelia.huck@de.ibm.com>
-