aboutsummaryrefslogtreecommitdiff
path: root/hw/s390x/s390-stattrib-kvm.c
AgeCommit message (Collapse)Author
2021-07-07target/s390x: move kvm files into kvm/Cho, Yu-Chen
move kvm files into kvm/ After the reshuffling, update MAINTAINERS accordingly. Make use of the new directory: target/s390x/kvm/ Signed-off-by: Claudio Fontana <cfontana@suse.de> Signed-off-by: Cho, Yu-Chen <acho@suse.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20210707105324.23400-14-acho@suse.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2021-05-02Do not include cpu.h if it's not really necessaryThomas Huth
Stop including cpu.h in files that don't need it. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <20210416171314.2074665-4-thuth@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2020-04-02vl/s390x: fixup ram sizes for compat machinesChristian Borntraeger
Older QEMU versions did fixup the ram size to match what can be reported via sclp. We need to mimic this behaviour for machine types 4.2 and older to not fail on inbound migration for memory sizes that do not fit. Old machines with proper aligned memory sizes are not affected. Alignment table: VM size (<=) | Alignment -------------------------- 1020M | 1M 2040M | 2M 4080M | 4M 8160M | 8M 16320M | 16M 32640M | 32M 65280M | 64M 130560M | 128M 261120M | 256M 522240M | 512M 1044480M | 1G 2088960M | 2G 4177920M | 4G 8355840M | 8G Suggested action is to replace unaligned -m value with a suitable aligned one or if a change to a newer machine type is possible, use a machine version >= 5.0. A future version might remove the compatibility handling. For machine types >= 5.0 we can simply use an increment size of 1M and use the full range of increment number which allows for all possible memory sizes. The old limitation of having a maximum of 1020 increments was added for standby memory, which we no longer support. With that we can now support even weird memory sizes like 10001234 MB. As we no longer fixup maxram_size as well, make other users use ram_size instead. Keep using maxram_size when setting the maximum ram size in KVM, as that will come in handy in the future when supporting memory hotplug (in contrast, storage keys and storage attributes for hotplugged memory will have to be migrated per RAM block in the future). Fixes: 3a12fc61af5c ("390x/s390-virtio-ccw: use memdev for RAM") Reported-by: Lukáš Doktor <ldoktor@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Acked-by: Igor Mammedov <imammedo@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20200401123754.109602-1-borntraeger@de.ibm.com> [CH: fixed up message on memory size fixup] Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-07-11s390x/storage attributes: fix CMMA_BLOCK_SIZE usageClaudio Imbrenda
The macro CMMA_BLOCK_SIZE was defined but not used, and a hardcoded value was instead used in the code. This patch fixes the value of CMMA_BLOCK_SIZE and uses it in the appropriate place in the code, and fixes another case of hardcoded value in the KVM backend, replacing it with the more appropriate constant KVM_S390_CMMA_SIZE_MAX. Signed-off-by: Claudio Imbrenda <imbrenda@linux.vnet.ibm.com> Message-Id: <1530787170-3101-1-git-send-email-imbrenda@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-01-22s390x: fix storage attributes migration for non-small guestsClaudio Imbrenda
Fix storage attribute migration so that it does not fail for guests with more than a few GB of RAM. With such guests, the index in the buffer would go out of bounds, usually by large amounts, thus receiving -EFAULT from the kernel. Migration itself would be successful, but storage attributes would then not be migrated completely. This patch fixes the out of bounds access, and thus migration of all storage attributes when the guest have large amounts of memory. Cc: qemu-stable@nongnu.org Signed-off-by: Claudio Imbrenda <imbrenda@linux.vnet.ibm.com> Fixes: 903fd80b03243476 ("s390x/migration: Storage attributes device") Message-Id: <1516297904-18188-1-git-send-email-imbrenda@linux.vnet.ibm.com> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2017-08-30s390x/s390-stattrib: Mark the storage attribute as not user_creatableThomas Huth
The storage attribute devices are only meant to be instantiated one time, internally. They can not be used by the user, so mark them with user_creatable = false. Suggested-by: Claudio Imbrenda <imbrenda@linux.vnet.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <1503576029-24264-1-git-send-email-thuth@redhat.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.vnet.ibm.com> Reviewed-by: Halil Pasic <pasic@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2017-08-30s390x/kvm: move KVM declarations and stubs to separate filesDavid Hildenbrand
Let's do it just like the other architectures. Introduce kvm-stub.c for stubs and kvm_s390x.h for the declarations. Change license to GPL2+ and keep copyright notice. As we are dropping the sysemu/kvm.h include from cpu.h, fix up includes. Suggested-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20170818114353.13455-18-david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2017-07-14s390x/migration: Storage attributes deviceClaudio Imbrenda
Storage attributes device, like we have for storage keys. Signed-off-by: Claudio Imbrenda <imbrenda@linux.vnet.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>