aboutsummaryrefslogtreecommitdiff
path: root/hw/s390x
AgeCommit message (Collapse)Author
2018-02-27Merge tag 'tags/s390-ccw-bios-2018-02-26' into s390-nextCornelia Huck
Boot menu patches by Collin L. Walling # gpg: Signature made Mon 26 Feb 2018 11:24:21 AM CET # gpg: using RSA key 2ED9D774FE702DB5 # gpg: Good signature from "Thomas Huth <th.huth@gmx.de>" [full] # gpg: aka "Thomas Huth <thuth@redhat.com>" [undefined] # gpg: aka "Thomas Huth <huth@tuxfamily.org>" [undefined] # gpg: aka "Thomas Huth <th.huth@posteo.de>" [unknown] * tag 'tags/s390-ccw-bios-2018-02-26': pc-bios/s390: Rebuild the s390x firmware images with the boot menu changes s390-ccw: interactive boot menu for scsi s390-ccw: use zipl values when no boot menu options are present s390-ccw: set cp_receive mask only when needed and consume pending service irqs s390-ccw: read user input for boot index via the SCLP console s390-ccw: print zipl boot menu s390-ccw: read stage2 boot loader data to find menu s390-ccw: set up interactive boot menu parameters s390-ccw: parse and set boot menu options s390-ccw: move auxiliary IPL data to separate location s390-ccw: update libc s390-ccw: refactor IPL structs s390-ccw: refactor eckd_block_num to use CHS s390-ccw: refactor boot map table code
2018-02-26s390x/sclp: remove memory hotplug supportDavid Hildenbrand
From an architecture point of view, nothing can be mapped into the address space on s390x. All there is is memory. Therefore there is also not really an interface to communicate such information to the guest. All we can do is specify the maximum ram address and guests can probe in that range if memory is available and usable (TPROT). Also memory hotplug is strange. The guest can decide at some point in time to add / remove memory in some range. While the hypervisor can deny to online an increment, all increments have to be predefined and there is no way of telling the guest about a newly "hotplugged" increment. So if we specify right now e.g. -m 2G,slots=2,maxmem=20G An ordinary fedora guest will happily online (hotplug) all memory, resulting in a guest consuming 20G. So it really behaves rather like -m 22G There is no way to hotplug memory from the outside like on other architectures. This is of course bad for upper management layers. As the guest can create/delete memory regions while it is running, of course migration support is not available and tricky to implement. With virtualization, it is different. We might want to map something into guest address space (e.g. fake DAX devices) and not detect it automatically as memory. So we really want to use the maxmem and slots parameter just like on all other architectures. Such devices will have to expose the applicable memory range themselves. To finally be able to provide memory hotplug to guests, we will need a new paravirtualized interface to do that (e.g. something into the direction of virtio-mem). This implies, that maxmem cannot be used for s390x memory hotplug anymore and has to go. This simplifies the code quite a bit. As migration support is not working, this change cannot really break migration as guests without slots and maxmem don't see the SCLP features. Also, the ram size calculation does not change. Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20180219174231.10874-1-david@redhat.com> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Acked-by: Matthew Rosato <mjrosato@linux.vnet.ibm.com> [CH: tweaked patch description, as discussed on list] Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-02-26qmp: expose s390-specific CPU infoViktor 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: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <1518797321-28356-2-git-send-email-mihajlov@linux.vnet.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-02-26s390/stattrib: Make SaveVMHandlers data staticDr. David Alan Gilbert
There's no need for this to be dynamic, make it static. Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20180212154903.8859-1-dgilbert@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.vnet.ibm.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-02-26s390-ccw: interactive boot menu for scsiCollin L. Walling
Interactive boot menu for scsi. This follows a similar procedure as the interactive menu for eckd dasd. An example follows: s390x Enumerated Boot Menu. 3 entries detected. Select from index 0 to 2. Signed-off-by: Collin L. Walling <walling@linux.vnet.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> [thuth: Added additional "break;" statement to avoid analyzer warnings] Signed-off-by: Thomas Huth <thuth@redhat.com>
2018-02-26s390-ccw: use zipl values when no boot menu options are presentCollin L. Walling
If no boot menu options are present, then flag the boot menu to use the zipl options that were set in the zipl configuration file (and stored on disk by zipl). These options are found at some offset prior to the start of the zipl boot menu banner. The zipl timeout value is limited to a 16-bit unsigned integer and stored as seconds, so we take care to convert it to milliseconds in order to conform to the rest of the boot menu functionality. This is limited to CCW devices. For reference, the zipl configuration file uses the following fields in the menu section: prompt=1 enable the boot menu timeout=X set the timeout to X seconds To explicitly disregard any boot menu options, then menu=off or <bootmenu enable='no' ... /> must be specified. Signed-off-by: Collin L. Walling <walling@linux.vnet.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2018-02-26s390-ccw: parse and set boot menu optionsCollin L. Walling
Set boot menu options for an s390 guest and store them in the iplb. These options are set via the QEMU command line option: -boot menu=on|off[,splash-time=X] or via the libvirt domain xml: <os> <bootmenu enable='yes|no' timeout='X'/> </os> Where X represents some positive integer representing milliseconds. Any value set for loadparm will override all boot menu options. If loadparm=PROMPT, then the menu will be enabled without a timeout. Signed-off-by: Collin L. Walling <walling@linux.vnet.ibm.com> Reviewed-by: Janosch Frank <frankja@linux.vnet.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2018-02-26s390-ccw: move auxiliary IPL data to separate locationCollin L. Walling
The s390-ccw firmware needs some information in support of the boot process which is not available on the native machine. Examples are the netboot firmware load address and now the boot menu parameters. While storing that data in unused fields of the IPL parameter block works, that approach could create problems if the parameter block definition should change in the future. Because then a guest could overwrite these fields using the set IPLB diagnose. In fact the data in question is of more global nature and not really tied to an IPL device, so separating it is rather logical. This commit introduces a new structure to hold firmware relevant IPL parameters set by QEMU. The data is stored at location 204 (dec) and can contain up to 7 32-bit words. This area is available to programming in the z/Architecture Principles of Operation and can thus safely be used by the firmware until the IPL has completed. Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com> Signed-off-by: Collin L. Walling <walling@linux.vnet.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> [thuth: fixed "4 + 8 * n" comment] Signed-off-by: Thomas Huth <thuth@redhat.com>
2018-02-09Merge remote-tracking branch 'remotes/armbru/tags/pull-misc-2018-02-07-v4' ↵Peter Maydell
into staging Miscellaneous patches for 2018-02-07 # gpg: Signature made Fri 09 Feb 2018 12:52:51 GMT # gpg: using RSA key 3870B400EB918653 # gpg: Good signature from "Markus Armbruster <armbru@redhat.com>" # gpg: aka "Markus Armbruster <armbru@pond.sub.org>" # Primary key fingerprint: 354B C8B3 D7EB 2A6B 6867 4E5F 3870 B400 EB91 8653 * remotes/armbru/tags/pull-misc-2018-02-07-v4: Move include qemu/option.h from qemu-common.h to actual users Drop superfluous includes of qapi/qmp/qjson.h Drop superfluous includes of qapi/qmp/dispatch.h Include qapi/qmp/qnull.h exactly where needed Include qapi/qmp/qnum.h exactly where needed Include qapi/qmp/qbool.h exactly where needed Include qapi/qmp/qstring.h exactly where needed Include qapi/qmp/qdict.h exactly where needed Include qapi/qmp/qlist.h exactly where needed Include qapi/qmp/qobject.h exactly where needed qdict qlist: Make most helper macros functions Eliminate qapi/qmp/types.h Typedef the subtypes of QObject in qemu/typedefs.h, too Include qmp-commands.h exactly where needed Drop superfluous includes of qapi/qmp/qerror.h Include qapi/error.h exactly where needed Drop superfluous includes of qapi-types.h and test-qapi-types.h Clean up includes Use #include "..." for our own headers, <...> for others vnc: use stubs for CONFIG_VNC=n dummy functions Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-02-09Move include qemu/option.h from qemu-common.h to actual usersMarkus 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: Eric Blake <eblake@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20180201111846.21846-20-armbru@redhat.com> [Semantic conflict with commit bdd6a90a9e in block/nvme.c resolved]
2018-02-09Include qapi/qmp/qdict.h exactly where neededMarkus Armbruster
This cleanup makes the number of objects depending on qapi/qmp/qdict.h drop from 4550 (out of 4743) to 368 in my "build everything" tree. For qapi/qmp/qobject.h, the number drops from 4552 to 390. While there, separate #include from file comment with a blank line. Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20180201111846.21846-13-armbru@redhat.com>
2018-02-09Include qmp-commands.h exactly where neededMarkus Armbruster
Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20180201111846.21846-7-armbru@redhat.com> [OSX breakage fixed]
2018-02-09Drop superfluous includes of qapi/qmp/qerror.hMarkus Armbruster
Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20180201111846.21846-6-armbru@redhat.com>
2018-02-09Include qapi/error.h exactly where neededMarkus Armbruster
This cleanup makes the number of objects depending on qapi/error.h drop from 1910 (out of 4743) to 1612 in my "build everything" tree. While there, separate #include from file comment with a blank line, and drop a useless comment on why qemu/osdep.h is included first. Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20180201111846.21846-5-armbru@redhat.com> [Semantic conflict with commit 34e304e975 resolved, OSX breakage fixed]
2018-02-09s390x/pci: use the right pal and pba in reg_ioat()Yi Min Zhao
When registering ioat, pba should be comprised of leftmost 52 bits and rightmost 12 binary zeros, and pal should be comprised of leftmost 52 bits and right most 12 binary ones. The lower 12 bits of words 5 and 7 of the FIB are ignored by the facility. Let's fixup this. Reviewed-by: Pierre Morel <pmorel@linux.vnet.ibm.com> Signed-off-by: Yi Min Zhao <zyimin@linux.vnet.ibm.com> Message-Id: <20180205072258.5968-4-zyimin@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-02-09s390x/pci: fixup global refreshYi Min Zhao
The VFIO common code doesn't provide the possibility to modify a previous mapping entry in another way than unmapping and mapping again with new properties. To avoid -EEXIST DMA mapping error, we introduce a GHashTable to store S390IOTLBEntry instances in order to cache the mapped entries. When intercepting rpcit instruction, ignore the identical mapped entries to avoid doing map operations multiple times and do unmap and re-map operations for the case of updating the valid entries. Acked-by: Pierre Morel <pmorel@linux.vnet.ibm.com> Signed-off-by: Yi Min Zhao <zyimin@linux.vnet.ibm.com> Message-Id: <20180205072258.5968-3-zyimin@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-02-09s390x/pci: fixup the code walking IOMMU tablesYi Min Zhao
Current s390x PCI IOMMU code is lack of flags' checking, including: 1) protection bit 2) table length 3) table offset 4) intermediate tables' invalid bit 5) format control bit This patch introduces a new struct named S390IOTLBEntry, and makes up these missed checkings. At the same time, inform the guest with the corresponding error number when the check fails. Finally, in order to get the error number, we export s390_guest_io_table_walk(). Reviewed-by: Pierre Morel <pmorel@linux.vnet.ibm.com> Signed-off-by: Yi Min Zhao <zyimin@linux.vnet.ibm.com> Message-Id: <20180205072258.5968-2-zyimin@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-02-09s390x/sclp: fix event mask handlingChristian Borntraeger
commit 67915de9f038 ("s390x/event-facility: variable-length event masks") switched the sclp receive/send mask. This broke the sclp lm console. Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Fixes: commit 67915de9f038 ("s390x/event-facility: variable-length event masks") Cc: Cornelia Huck <cohuck@redhat.com> Cc: Jason J. Herne <jjherne@linux.vnet.ibm.com> Cc: qemu-stable@nongnu.org Message-Id: <20180202094241.59537-1-borntraeger@de.ibm.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.vnet.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-02-09s390x/flic: cache the common flic class in a central functionDavid Hildenbrand
This avoids tons of conversions when handling interrupts. Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20180129125623.21729-19-david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-02-09s390x/tcg: remove SMP warningDavid Hildenbrand
We should be pretty good in shape now. Floating interrupts are working and atomic instructions should be atomic. Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20180129125623.21729-15-david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-02-09Use #include "..." for our own headers, <...> for othersMarkus Armbruster
System headers should be included with <...>, our own headers with "...". Offenders tracked down with an ugly, brittle and probably buggy Perl script. Previous iteration was commit a9c94277f0. Delete inclusions of "string.h" and "strings.h" instead of fixing them to <string.h> and <strings.h>, because we always include these via osdep.h. Put the cleaned up system header includes first. While there, separate #include from file comment with exactly one blank line. Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20180201111846.21846-2-armbru@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>
2018-01-22hw/s390x: Replace fprintf(stderr, "*\n" with qemu_log_mask()Alistair Francis
One fprintf(stderr, was manually converted to a qemu_log_mask(LOG_GUEST_ERROR, Signed-off-by: Alistair Francis <alistair.francis@xilinx.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <3f49c0ff601f27534d4536c87c00d01c233e067f.1513790495.git.alistair.francis@xilinx.com> [CH: tweaked commit message] Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-01-22s390x/sclp: fix missing be conversionDavid Hildenbrand
Linux crashes right now if maxmem > mem is specified on the command line. On s390x, the guest can hotplug memory itself right now - very weird - and e.g. Fedora 27 will simply add all memory it can when booting. So now, we have at least the same behavior on TCG and KVM. Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20171218224616.21030-3-david@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-01-22s390x/sclp: fixup highest CPU addressChristian Borntraeger
The highest cpu address is not the same as max_cpus. max_cpus counts from 1 while the cpu address starts at 0. Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: Jason J. Herne <jjherne@linux.vnet.ibm.com> Message-Id: <20171219082807.84494-1-borntraeger@de.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-01-19possible_cpus: add CPUArchId::type fieldIgor 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: 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>
2018-01-11Merge remote-tracking branch 'origin/master' into HEADMichael S. Tsirkin
Resolve conflicts around apb. Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-12-18misc: remove duplicated includesPhilippe Mathieu-Daudé
exec: housekeeping (funny since 02d0e095031) applied using ./scripts/clean-includes Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Acked-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2017-12-18Remove empty statementsLadi Prosek
Thanks to Laszlo Ersek for spotting the double semicolon in target/i386/kvm.c I have trivially grepped the tree for ';;' in C files. Suggested-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Ladi Prosek <lprosek@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2017-12-15s390-ccw-virtio: allow for systems larger that 7.999TBChristian 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: Christian Borntraeger <borntraeger@de.ibm.com> Message-Id: <20171211122146.162430-1-borntraeger@de.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> [CH: 1UL -> 1ULL in KVM_MEM_MAX_NR_PAGES; build fix on 32 bit hosts] Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2017-12-14s390x: change the QEMU cpu model to a stripped down z12David 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: David 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: Cornelia Huck <cohuck@redhat.com>
2017-12-14s390x/css: attach css bridgeCornelia Huck
Logically, the css bridge should be attached to the machine. Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Tested-by: Bjoern Walk <bwalk@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2017-12-14s390x: deprecate s390-squash-mcss machine propHalil 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: Halil Pasic <pasic@linux.vnet.ibm.com> Message-Id: <20171206144438.28908-3-pasic@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2017-12-14s390x/css: unrestrict cssidsHalil 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 8ed179c937 ("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: Halil Pasic <pasic@linux.vnet.ibm.com> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com> Message-Id: <20171206144438.28908-2-pasic@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2017-12-14s390x/pci: search for subregion inside the BARsPierre Morel
When dispatching memory access to PCI BAR region, we must look for possible subregions, used by the PCI device to map different memory areas inside the same PCI BAR. Since the data offset we received is calculated starting at the region start address we need to adjust the offset for the subregion. The data offset inside the subregion is calculated by substracting the subregion's starting address from the data offset in the region. The access to the MSIX region is now handled in a generic way, we do not need the specific trap_msix() function anymore. Signed-off-by: Pierre Morel <pmorel@linux.vnet.ibm.com> Reviewed-by: Yi Min Zhao <zyimin@linux.vnet.ibm.com> Message-Id: <1512046530-17773-8-git-send-email-pmorel@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2017-12-14s390x/pci: move the memory region write from pcistgPierre Morel
Let's move the memory region write from pcistg into a dedicated function. This allows us to prepare a later patch searching for subregions inside of the memory region. Signed-off-by: Pierre Morel <pmorel@linux.vnet.ibm.com> Reviewed-by: Yi Min Zhao <zyimin@linux.vnet.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <1512046530-17773-7-git-send-email-pmorel@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2017-12-14s390x/pci: move the memory region read from pcilgPierre Morel
Let's move the memory region read from pcilg into a dedicated function. This allows us to prepare a later patch. Signed-off-by: Pierre Morel <pmorel@linux.vnet.ibm.com> Reviewed-by: Yi Min Zhao <zyimin@linux.vnet.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <1512046530-17773-6-git-send-email-pmorel@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2017-12-14s390x/pci: rework PCI STORE BLOCKPierre Morel
Enhance the fault detection. Fixup the precedence to check the destination path existance before checking for the source accessibility. Add the maxstbl entry to both the Query PCI Function Group response and the PCIBusDevice structure. Initialize the maxstbl to 128 per default until we get the actual data from the hardware. Signed-off-by: Pierre Morel <pmorel@linux.vnet.ibm.com> Reviewed-by: Yi Min Zhao <zyimin@linux.vnet.ibm.com> Message-Id: <1512046530-17773-5-git-send-email-pmorel@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2017-12-14s390x/pci: rework PCI LOADPierre Morel
Enhance the fault detection, correction of the fault reporting. Signed-off-by: Pierre Morel <pmorel@linux.vnet.ibm.com> Reviewed-by: Yi Min Zhao <zyimin@linux.vnet.ibm.com> Message-Id: <1512046530-17773-4-git-send-email-pmorel@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2017-12-14s390x/pci: rework PCI STOREPierre Morel
Enhance the fault detection, correction of the fault reporting. Signed-off-by: Pierre Morel <pmorel@linux.vnet.ibm.com> Reviewed-by: Yi Min Zhao <zyimin@linux.vnet.ibm.com> Message-Id: <1512046530-17773-3-git-send-email-pmorel@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2017-12-14s390x/pci: factor out endianess conversionPierre Morel
There are two places where the same endianness conversion is done. Let's factor this out into a static function. Note that the conversion must always be done for data in a register: The S390 BE guest converted date to le before issuing the instruction. After interception in a BE host: ZPCI VFIO using pwrite must make the conversion back for the BE kernel. Kernel will do BE to le translation when loading the register for the real instruction. After interception in a le host: TCG stores a BE register in le, swapping bytes. But since the data in the register was already le it is now BE ZPCI VFIO must convert it to le before writing to the PCI memory. In both cases ZPCI VFIO must swap the bytes from the register. Signed-off-by: Pierre Morel <pmorel@linux.vnet.ibm.com> Reviewed-by: Yi Min Zhao <zyimin@linux.vnet.ibm.com> Message-Id: <1512046530-17773-2-git-send-email-pmorel@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2017-12-14s390x: handle exceptions during s390_cpu_virt_mem_rw() correctly (TCG)David Hildenbrand
s390_cpu_virt_mem_rw() must always return, so callers can react on an exception (e.g. see ioinst_handle_stcrw()). However, for TCG we always have to exit the cpu loop (and restore the cpu state before that) if we injected a program interrupt. So let's introduce and use s390_cpu_virt_mem_handle_exc() in code that is not purely KVM. Directly pass the retaddr we already have available in these functions. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20171130162744.25442-8-david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2017-12-14s390x/pci: pass the retaddr to all PCI instructionsDavid Hildenbrand
Once we wire up TCG, we will need the retaddr to correctly inject program interrupts. As we want to get rid of the function program_interrupt(), convert PCI code too. For KVM, we can simply use RA_IGNORED. Convert program_interrupt() to s390_program_interrupt() directly, making use of the passed address. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20171130162744.25442-6-david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2017-12-14s390x/tcg: rip out dead tpi codeDavid Hildenbrand
It is broken and not even wired up. We'll add a new handler soon, but that will live somewhere else. Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20171130162744.25442-4-david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2017-12-14s390x: introduce 2.12 compat machineCornelia Huck
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2017-12-05pci: Eliminate redundant PCIDevice::bus pointerDavid Gibson
The bus pointer in PCIDevice is basically redundant with QOM information. It's always initialized to the qdev_get_parent_bus(), the only difference is the type. Therefore this patch eliminates the field, instead creating a pci_get_bus() helper to do the type mangling to derive it conveniently from the QOM Device object underneath. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com>
2017-12-05pci: Add pci_dev_bus_num() helperDavid Gibson
A fair proportion of the users of pci_bus_num() want to get the bus number on a specific device, so first have to look up the bus from the device then call it. This adds a helper to do that (since we're going to make looking up the bus slightly more verbose). Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com>
2017-12-05pci: Rename root bus initialization functions for clarityDavid Gibson
pci_bus_init(), pci_bus_new_inplace(), pci_bus_new() and pci_register_bus() are misleadingly named. They're not used for initializing *any* PCI bus, but only for a root PCI bus. Non-root buses - i.e. ones under a logical PCI to PCI bridge - are instead created with a direct qbus_create_inplace() (see pci_bridge_initfn()). This patch renames the functions to make it clear they're only used for a root bus. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com>
2017-11-24s390/kvm_virtio/linux-headers: remove traces of old virtio transportChristian Borntraeger
We no longer support the old s390 transport, neither does the newest Linux kernel. Remove it from the linux header script as well as the s390x virtio code. We still should handle the VIRTIO_NOTIFY hypercall, to tolerate early printk on older guest kernels without an sclp console. We continue to ignore these events. Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Message-Id: <20171115154223.109991-1-borntraeger@de.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2017-11-08s390x/pci: let pci devices start in configured modeChristian Borntraeger
Currently, to enable a pci device in the guest, the user has to issue echo 1 > /sys/bus/pci/slots/00000000/power. This is not what people expect. On an LPAR, the user can put a PCI device in configured or deconfigured state via IOCDS. The "start in deconfigured state" can be used for "sharing" a pci function across LPARs. This is not what we are going to use in KVM, so always start configured. Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Acked-by: Yi Min Zhao <zyimin@linux.vnet.ibm.com> Reviewed-by: Pierre Morel <pmorel@linux.vnet.ibm.com> Message-Id: <20171107175455.73793-2-borntraeger@de.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
generated by cgit v1.2.3 (git 2.26.2) at 2024-12-12 08:13:58 +0000