aboutsummaryrefslogtreecommitdiff
path: root/hw/s390x/3270-ccw.c
AgeCommit message (Collapse)AuthorFilesLines
2021-06-21s390x/css: Refactor IRB constructionEric Farman1-0/+1
Currently, all subchannel types have "sense data" copied into the IRB.ECW space, and a couple flags enabled in the IRB.SCSW and IRB.ESW. But for passthrough (vfio-ccw) subchannels, this data isn't populated in the first place, so enabling those flags leads to unexpected behavior if the guest tries to process the sense data (zeros) in the IRB.ECW. Let's add a subchannel callback that builds these portions of the IRB, and move the existing code into a routine for those virtual subchannels. The passthrough subchannels will be able to piggy-back onto this later. Signed-off-by: Eric Farman <farman@linux.ibm.com> Message-Id: <20210617232537.1337506-4-farman@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2021-05-20hw/s390x/ccw: Register qbus type in abstract TYPE_CCW_DEVICE parentPhilippe Mathieu-Daudé1-1/+0
Instead of having all TYPE_CCW_DEVICE children set the bus type to TYPE_VIRTUAL_CSS_BUS, do it once in the abstract parent. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Acked-by: Eric Farman <farman@linux.ibm.com> Message-Id: <20210424145313.3287400-1-f4bug@amsat.org> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2021-05-02Do not include cpu.h if it's not really necessaryThomas Huth1-1/+0
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>
2021-04-09s390x: css: report errors from ccw_dstream_read/writePierre Morel1-1/+4
ccw_dstream_read/write functions returned values are sometime not taking into account and reported back to the upper level of interpretation of CCW instructions. It follows that accessing an invalid address does not trigger a subchannel status program check to the guest as it should. Let's test the return values of ccw_dstream_write[_buf] and ccw_dstream_read[_buf] and report it to the caller. Cc: qemu-stable@nongnu.org Signed-off-by: Pierre Morel <pmorel@linux.ibm.com> Acked-by: Halil Pasic <pasic@linux.ibm.com> Message-Id: <1617899529-9329-2-git-send-email-pmorel@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2020-01-24qdev: set properties with device_class_set_props()Marc-André Lureau1-1/+1
The following patch will need to handle properties registration during class_init time. Let's use a device_class_set_props() setter. spatch --macro-file scripts/cocci-macro-file.h --sp-file ./scripts/coccinelle/qdev-set-props.cocci --keep-comments --in-place --dir . @@ typedef DeviceClass; DeviceClass *d; expression val; @@ - d->props = val + device_class_set_props(d, val) Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20200110153039.1379601-20-marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-08-16Include hw/qdev-properties.h lessMarkus Armbruster1-0/+2
In my "build everything" tree, changing hw/qdev-properties.h triggers a recompile of some 2700 out of 6600 objects (not counting tests and objects that don't depend on qemu/osdep.h). Many places including hw/qdev-properties.h (directly or via hw/qdev.h) actually need only hw/qdev-core.h. Include hw/qdev-core.h there instead. hw/qdev.h is actually pointless: all it does is include hw/qdev-core.h and hw/qdev-properties.h, which in turn includes hw/qdev-core.h. Replace the remaining uses of hw/qdev.h by hw/qdev-properties.h. While there, delete a few superfluous inclusions of hw/qdev-core.h. Touching hw/qdev-properties.h now recompiles some 1200 objects. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: "Daniel P. Berrangé" <berrange@redhat.com> Cc: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20190812052359.30071-22-armbru@redhat.com>
2019-04-03hw/s390x/3270-ccw: avoid taking address of fields in packed structDaniel P. Berrangé1-4/+4
Compiling with GCC 9 complains hw/s390x/3270-ccw.c: In function ‘emulated_ccw_3270_cb’: hw/s390x/3270-ccw.c:81:19: error: taking address of packed member of ‘struct SCHIB’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 81 | SCSW *s = &sch->curr_status.scsw; | ^~~~~~~~~~~~~~~~~~~~~~ This local variable is only present to save a little bit of typing when setting the field later. Get rid of this to avoid the warning about unaligned accesses. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20190329111104.17223-15-berrange@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-08-20s390x: remove 's390-squash-mcss' optionCornelia Huck1-4/+1
This option has been deprecated for two releases; remove it. Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Acked-by: Halil Pasic <pasic@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2017-12-14s390x/css: unrestrict cssidsHalil Pasic1-1/+1
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-10-06s390x: sort some devices into categoriesCornelia Huck1-0/+1
Add missing categorizations for some s390x devices: - zpci device -> misc - 3270 -> display - vfio-ccw -> misc Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2017-10-06s390x/3270: IDA support for 3270 via CcwDataStreamHalil Pasic1-2/+2
Let us convert the 3270 code so it uses the recently introduced CcwDataStream abstraction instead of blindly assuming direct data access. This patch does not change behavior beyond introducing IDA support: for direct data access CCWs everything stays as-is. (If there are bugs, they are also preserved). 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: <20170920172314.102710-2-pasic@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2017-07-05s390x/3270: fix instruction interception handlerDong Jia Shi1-0/+1
Commit bab482d7405f ("s390x/css: ccw translation infrastructure") introduced instruction interception handler for different types of subchannels. For emulated 3270 devices, we should assign the virtual subchannel handler to them during device realization process, or 3270 will not work. Fixes: bab482d7405f ("s390x/css: ccw translation infrastructure") Reviewed-by: Jing Liu <liujbjl@linux.vnet.ibm.com> Reviewed-by: Halil Pasic <pasic@linux.vnet.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
2017-05-19s390x/css: realize css_create_schDong Jia Shi1-1/+5
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: Pierre Morel <pmorel@linux.vnet.ibm.com> Signed-off-by: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com> Message-Id: <20170517004813.58227-6-bjsdjshi@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2017-05-04s390x/3270: 3270 data stream handlingJing Liu1-0/+75
This introduces the input and output handlers for 3270 device, setting up the data tunnel among guest kernel, qemu and the 3270 client. After the client connected and TN3270 handshake done, signal the not-ready to ready status by an unsolicited device-end interrupt, and then the 3270 data stream could be handled correctly between the channel and socket. Multiple commands generated by "Reset" key on x3270 are not supported now, just simply terminate the connection. Signed-off-by: Jing Liu <liujbjl@linux.vnet.ibm.com> Signed-off-by: Yang Chen <bjcyang@linux.vnet.ibm.com> Reviewed-by: QingFeng Hao <haoqf@linux.vnet.ibm.com> Reviewed-by: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2017-05-04s390x/3270: Add abstract emulated ccw-attached 3270 deviceYang Chen1-0/+99
This introduces the infrastructure for the emulated 3270 devices, which will be attached to the virtual-css-bus. Signed-off-by: Yang Chen <bjcyang@linux.vnet.ibm.com> Signed-off-by: Jing Liu <liujbjl@linux.vnet.ibm.com> Reviewed-by: QingFeng Hao <haoqf@linux.vnet.ibm.com> Reviewed-by: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>