aboutsummaryrefslogtreecommitdiff
path: root/pc-bios/s390-ccw/virtio-scsi.c
AgeCommit message (Collapse)Author
2023-06-29s390-ccw: Getting rid of ulongJuan Quintela
Any good reason why this still exist? I can understand u* and __u* to be linux kernel like, but ulong? Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com> Message-Id: <20230629104821.194859-2-thuth@redhat.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
2022-08-01misc: fix commonly doubled up wordsDaniel P. Berrangé
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20220707163720.1421716-5-berrange@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
2022-07-06pc-bios/s390-ccw: Split virtio-scsi code from virtio_blk_setup_device()Thomas Huth
The next patch is going to add more virtio-block specific code to virtio_blk_setup_device(), and if the virtio-scsi code is also in there, this is more cumbersome. And the calling function virtio_setup() in main.c looks at the device type already anyway, so it's more logical to separate the virtio-scsi stuff into a new function in virtio-scsi.c instead. Message-Id: <20220704111903.62400-10-thuth@redhat.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2020-10-06pc-bios/s390-ccw: Do not bail out early if not finding a SCSI diskThomas Huth
In case the user did not specify a boot device, we want to continue looking for other devices if there are no valid SCSI disks on a virtio- scsi controller. As a first step, do not panic in this case and let the control flow carry the error to the upper functions instead. Message-Id: <20200806105349.632-6-thuth@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2020-07-02pc-bios: s390x: Move sleep and yield to helper.hJanosch Frank
They are definitely helper functions. Signed-off-by: Janosch Frank <frankja@linux.ibm.com> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Message-Id: <20200624075226.92728-4-frankja@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2020-07-02pc-bios: s390x: Consolidate timing functions into time.hJanosch Frank
Let's consolidate timing related functions into one header. Signed-off-by: Janosch Frank <frankja@linux.ibm.com> Acked-by: Thomas Huth <thuth@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Message-Id: <20200624075226.92728-3-frankja@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2017-11-20pc-bios/s390-ccw: Fix problem with invalid virtio-scsi LUN when rebootingThomas Huth
When rebooting a guest that has a virtio-scsi disk, the s390-ccw bios sometimes bails out with an error message like this: ! SCSI cannot report LUNs: STATUS=02 RSPN=70 KEY=05 CODE=25 QLFR=00, sure ! Enabling the scsi_req* tracing in QEMU shows that the ccw bios is trying to execute the REPORT LUNS SCSI command with a LUN != 0, and this causes the SCSI command to fail. Looks like we neither clear the BSS of the s390-ccw bios during reboot, nor do we explicitly set the default_scsi_device.lun value to 0, so this variable can contain random values from the OS after the reboot. By setting this variable explicitly to 0, the problem is fixed and the reboots always succeed. Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1514352 Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <1510942228-22822-1-git-send-email-thuth@redhat.com> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2017-07-14pc-bios/s390-ccw: Move libc functions to separate headerThomas Huth
The upcoming netboot code will use the libc from SLOF. To be able to still use s390-ccw.h there, the libc related functions in this header have to be moved to a different location. And while we're at it, remove the duplicate memcpy() function from sclp.c. Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <1499863793-18627-2-git-send-email-thuth@redhat.com> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
2017-05-19pc-bios/s390-ccw: Build a reasonable max_sectors limitEric Farman
Now that we've read all the possible limits that have been defined for a virtio-scsi controller and the disk we're booting from, it's possible that we are STILL going to exceed the limits of the host device. For example, a "-device scsi-generic" device does not support the Block Limits VPD page. So, let's fallback to something that seems to work for most boot configurations if larger values were specified (including if nothing was explicitly specified, and we took default values). Signed-off-by: Eric Farman <farman@linux.vnet.ibm.com> Message-Id: <20170510155359.32727-8-farman@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2017-05-19pc-bios/s390-ccw: Get Block Limits VPD device dataEric Farman
The "Block Limits" Inquiry VPD page is optional for any SCSI device, but if it's supported it provides a hint of the maximum I/O transfer length for this particular device. If this page is supported by the disk, let's issue that Inquiry and use the minimum of it and the SCSI controller limit. That will cover this scenario: qemu-system-s390x ... -device virtio-scsi-ccw,id=scsi0,max_sectors=32768 ... -drive file=/dev/sda,if=none,id=drive0,format=raw ... -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0, drive=drive0,id=disk0,max_io_size=1048576 controller: 32768 sectors x 512 bytes/sector = 16777216 bytes disk: 1048576 bytes Now that we have a limit for a virtio-scsi disk, compare that with the limit for the virtio-scsi controller when we actually build the I/O. The minimum of these two limits should be the one we use. Signed-off-by: Eric Farman <farman@linux.vnet.ibm.com> Message-Id: <20170510155359.32727-7-farman@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2017-05-19pc-bios/s390-ccw: Get list of supported VPD pagesEric Farman
The "Supported Pages" Inquiry EVPD page is mandatory for all SCSI devices, and is used as a gateway for what VPD pages the device actually supports. Let's issue this Inquiry, and dump that list with the debug facility. Signed-off-by: Eric Farman <farman@linux.vnet.ibm.com> Message-Id: <20170510155359.32727-6-farman@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2017-05-19pc-bios/s390-ccw: Refactor scsi_inquiry functionEric Farman
If we want to issue any of the SCSI Inquiry EVPD pages, which we do, we could use this function to issue both types of commands with a little bit of refactoring. Signed-off-by: Eric Farman <farman@linux.vnet.ibm.com> Message-Id: <20170510155359.32727-5-farman@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2017-05-19pc-bios/s390-ccw: Break up virtio-scsi read into multiplesEric Farman
A virtio-scsi request that goes through the host sd driver and exceeds the maximum transfer size is automatically broken up for us. But the equivalent request going to the sg driver presumes that any length requirements have already been honored. Let's use the max_sectors field on the virtio-scsi controller device, and break up all requests (both sd and sg) to avoid this problem. Signed-off-by: Eric Farman <farman@linux.vnet.ibm.com> Message-Id: <20170510155359.32727-4-farman@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2017-05-19pc-bios/s390-ccw: Move SCSI block factor to outer readEric Farman
Simple refactoring so that the blk_factor adjustment is moved into virtio_scsi_read_many routine, in preparation for another change. Signed-off-by: Eric Farman <farman@linux.vnet.ibm.com> Message-Id: <20170510155359.32727-3-farman@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2017-05-19pc-bios/s390-ccw: Remove duplicate blk_factor adjustmentEric Farman
When using virtio-scsi, we multiply the READ(10) data_size by a block factor twice when building the I/O. This is fine, since it's only 1 for SCSI disks, but let's clean it up. Signed-off-by: Eric Farman <farman@linux.vnet.ibm.com> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Message-Id: <20170510155359.32727-2-farman@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-07-11pc-bios/s390-ccw: Pass selected SCSI device to IPLEugene (jno) Dvurechenski
There is ,bootindex=%d argument to specify the lookup order of boot devices. If a bootindex assigned to the device, then IPL Parameter Info Block is created for that device when it is IPLed from. If it is a mere SCSI device (not FCP), then IPIB is created with a special SCSI type and its fields are used to store SCSI address of the device. This new ipl block is private to qemu for now. If the device to IPL from is specified this way, then SCSI bus lookup is bypassed and prescribed devices uses the address specified. Signed-off-by: Eugene (jno) Dvurechenski <jno@linux.vnet.ibm.com> Signed-off-by: Alexander Yarygin <yarygin@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-03-23pc-bios/s390-ccw: add virtio-scsi implementationEugene (jno) Dvurechenski
Add virtio-scsi.[ch] with primary implementation of virtio-scsi. Signed-off-by: Eugene (jno) Dvurechenski <jno@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
generated by cgit v1.2.3 (git 2.26.2) at 2024-12-19 07:02:35 +0000