Revision tags: v8.0.2, v8.0.1, v7.2.3 |
|
#
f7f2f96f |
| 10-May-2023 |
Juan Quintela <quintela@redhat.com> |
s390-ccw: Getting rid of ulong
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
s390-ccw: Getting rid of ulong
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>
show more ...
|
Revision tags: v8.0.2, v8.0.1, v7.2.3 |
|
#
f7f2f96f |
| 10-May-2023 |
Juan Quintela <quintela@redhat.com> |
s390-ccw: Getting rid of ulong
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
s390-ccw: Getting rid of ulong
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>
show more ...
|
Revision tags: v7.2.2, v8.0.0, v8.0.0-rc4, v8.0.0-rc3, v7.2.1, v8.0.0-rc2, v8.0.0-rc1, v8.0.0-rc0, v7.2.0, v7.2.0-rc4, v7.2.0-rc3, v7.2.0-rc2, v7.2.0-rc1, v7.2.0-rc0, v7.1.0, v7.1.0-rc4, v7.1.0-rc3, v7.1.0-rc2, v7.1.0-rc1, v7.1.0-rc0 |
|
#
07082488 |
| 04-Jul-2022 |
Thomas Huth <thuth@redhat.com> |
pc-bios/s390-ccw/virtio: Beautify the code for reading virtqueue configuration
It looks nicer if we separate the run_ccw() from the IPL_assert() statement, and the error message should talk about "v
pc-bios/s390-ccw/virtio: Beautify the code for reading virtqueue configuration
It looks nicer if we separate the run_ccw() from the IPL_assert() statement, and the error message should talk about "virtio device" instead of "block device", since this code is nowadays used for non-block (i.e. network) devices, too.
Message-Id: <20220704111903.62400-9-thuth@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
show more ...
|
#
aa5c69ce |
| 04-Jul-2022 |
Thomas Huth <thuth@redhat.com> |
pc-bios/s390-ccw/virtio: Read device config after feature negotiation
Feature negotiation should be done first, since some fields in the config area can depend on the negotiated features and thus sh
pc-bios/s390-ccw/virtio: Read device config after feature negotiation
Feature negotiation should be done first, since some fields in the config area can depend on the negotiated features and thus should rather be read afterwards.
While we're at it, also adjust the error message here a little bit (the code is nowadays used for non-block virtio devices, too).
Message-Id: <20220704111903.62400-8-thuth@redhat.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
show more ...
|
#
175aa06a |
| 04-Jul-2022 |
Thomas Huth <thuth@redhat.com> |
pc-bios/s390-ccw/virtio: Set missing status bits while initializing
According chapter "3.1.1 Driver Requirements: Device Initialization" of the Virtio specification (v1.1), a driver for a device has
pc-bios/s390-ccw/virtio: Set missing status bits while initializing
According chapter "3.1.1 Driver Requirements: Device Initialization" of the Virtio specification (v1.1), a driver for a device has to set the ACKNOWLEDGE and DRIVER bits in the status field after resetting the device. The s390-ccw bios skipped these steps so far and seems like QEMU never cared. Anyway, it's better to follow the spec, so let's set these bits now in the right spots, too.
Message-Id: <20220704111903.62400-7-thuth@redhat.com> Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
show more ...
|
Revision tags: v7.2.2, v8.0.0, v8.0.0-rc4, v8.0.0-rc3, v7.2.1, v8.0.0-rc2, v8.0.0-rc1, v8.0.0-rc0, v7.2.0, v7.2.0-rc4, v7.2.0-rc3, v7.2.0-rc2, v7.2.0-rc1, v7.2.0-rc0, v7.1.0, v7.1.0-rc4, v7.1.0-rc3, v7.1.0-rc2, v7.1.0-rc1, v7.1.0-rc0 |
|
#
07082488 |
| 04-Jul-2022 |
Thomas Huth <thuth@redhat.com> |
pc-bios/s390-ccw/virtio: Beautify the code for reading virtqueue configuration
It looks nicer if we separate the run_ccw() from the IPL_assert() statement, and the error message should talk about "v
pc-bios/s390-ccw/virtio: Beautify the code for reading virtqueue configuration
It looks nicer if we separate the run_ccw() from the IPL_assert() statement, and the error message should talk about "virtio device" instead of "block device", since this code is nowadays used for non-block (i.e. network) devices, too.
Message-Id: <20220704111903.62400-9-thuth@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
show more ...
|
#
aa5c69ce |
| 04-Jul-2022 |
Thomas Huth <thuth@redhat.com> |
pc-bios/s390-ccw/virtio: Read device config after feature negotiation
Feature negotiation should be done first, since some fields in the config area can depend on the negotiated features and thus sh
pc-bios/s390-ccw/virtio: Read device config after feature negotiation
Feature negotiation should be done first, since some fields in the config area can depend on the negotiated features and thus should rather be read afterwards.
While we're at it, also adjust the error message here a little bit (the code is nowadays used for non-block virtio devices, too).
Message-Id: <20220704111903.62400-8-thuth@redhat.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
show more ...
|
#
175aa06a |
| 04-Jul-2022 |
Thomas Huth <thuth@redhat.com> |
pc-bios/s390-ccw/virtio: Set missing status bits while initializing
According chapter "3.1.1 Driver Requirements: Device Initialization" of the Virtio specification (v1.1), a driver for a device has
pc-bios/s390-ccw/virtio: Set missing status bits while initializing
According chapter "3.1.1 Driver Requirements: Device Initialization" of the Virtio specification (v1.1), a driver for a device has to set the ACKNOWLEDGE and DRIVER bits in the status field after resetting the device. The s390-ccw bios skipped these steps so far and seems like QEMU never cared. Anyway, it's better to follow the spec, so let's set these bits now in the right spots, too.
Message-Id: <20220704111903.62400-7-thuth@redhat.com> Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
show more ...
|
Revision tags: v7.2.2, v8.0.0, v8.0.0-rc4, v8.0.0-rc3, v7.2.1, v8.0.0-rc2, v8.0.0-rc1, v8.0.0-rc0, v7.2.0, v7.2.0-rc4, v7.2.0-rc3, v7.2.0-rc2, v7.2.0-rc1, v7.2.0-rc0, v7.1.0, v7.1.0-rc4, v7.1.0-rc3, v7.1.0-rc2, v7.1.0-rc1, v7.1.0-rc0 |
|
#
07082488 |
| 04-Jul-2022 |
Thomas Huth <thuth@redhat.com> |
pc-bios/s390-ccw/virtio: Beautify the code for reading virtqueue configuration
It looks nicer if we separate the run_ccw() from the IPL_assert() statement, and the error message should talk about "v
pc-bios/s390-ccw/virtio: Beautify the code for reading virtqueue configuration
It looks nicer if we separate the run_ccw() from the IPL_assert() statement, and the error message should talk about "virtio device" instead of "block device", since this code is nowadays used for non-block (i.e. network) devices, too.
Message-Id: <20220704111903.62400-9-thuth@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
show more ...
|
#
aa5c69ce |
| 04-Jul-2022 |
Thomas Huth <thuth@redhat.com> |
pc-bios/s390-ccw/virtio: Read device config after feature negotiation
Feature negotiation should be done first, since some fields in the config area can depend on the negotiated features and thus sh
pc-bios/s390-ccw/virtio: Read device config after feature negotiation
Feature negotiation should be done first, since some fields in the config area can depend on the negotiated features and thus should rather be read afterwards.
While we're at it, also adjust the error message here a little bit (the code is nowadays used for non-block virtio devices, too).
Message-Id: <20220704111903.62400-8-thuth@redhat.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
show more ...
|
#
175aa06a |
| 04-Jul-2022 |
Thomas Huth <thuth@redhat.com> |
pc-bios/s390-ccw/virtio: Set missing status bits while initializing
According chapter "3.1.1 Driver Requirements: Device Initialization" of the Virtio specification (v1.1), a driver for a device has
pc-bios/s390-ccw/virtio: Set missing status bits while initializing
According chapter "3.1.1 Driver Requirements: Device Initialization" of the Virtio specification (v1.1), a driver for a device has to set the ACKNOWLEDGE and DRIVER bits in the status field after resetting the device. The s390-ccw bios skipped these steps so far and seems like QEMU never cared. Anyway, it's better to follow the spec, so let's set these bits now in the right spots, too.
Message-Id: <20220704111903.62400-7-thuth@redhat.com> Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
show more ...
|
Revision tags: v7.2.2, v8.0.0, v8.0.0-rc4, v8.0.0-rc3, v7.2.1, v8.0.0-rc2, v8.0.0-rc1, v8.0.0-rc0, v7.2.0, v7.2.0-rc4, v7.2.0-rc3, v7.2.0-rc2, v7.2.0-rc1, v7.2.0-rc0, v7.1.0, v7.1.0-rc4, v7.1.0-rc3, v7.1.0-rc2, v7.1.0-rc1, v7.1.0-rc0 |
|
#
07082488 |
| 04-Jul-2022 |
Thomas Huth <thuth@redhat.com> |
pc-bios/s390-ccw/virtio: Beautify the code for reading virtqueue configuration
It looks nicer if we separate the run_ccw() from the IPL_assert() statement, and the error message should talk about "v
pc-bios/s390-ccw/virtio: Beautify the code for reading virtqueue configuration
It looks nicer if we separate the run_ccw() from the IPL_assert() statement, and the error message should talk about "virtio device" instead of "block device", since this code is nowadays used for non-block (i.e. network) devices, too.
Message-Id: <20220704111903.62400-9-thuth@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
show more ...
|
#
aa5c69ce |
| 04-Jul-2022 |
Thomas Huth <thuth@redhat.com> |
pc-bios/s390-ccw/virtio: Read device config after feature negotiation
Feature negotiation should be done first, since some fields in the config area can depend on the negotiated features and thus sh
pc-bios/s390-ccw/virtio: Read device config after feature negotiation
Feature negotiation should be done first, since some fields in the config area can depend on the negotiated features and thus should rather be read afterwards.
While we're at it, also adjust the error message here a little bit (the code is nowadays used for non-block virtio devices, too).
Message-Id: <20220704111903.62400-8-thuth@redhat.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
show more ...
|
#
175aa06a |
| 04-Jul-2022 |
Thomas Huth <thuth@redhat.com> |
pc-bios/s390-ccw/virtio: Set missing status bits while initializing
According chapter "3.1.1 Driver Requirements: Device Initialization" of the Virtio specification (v1.1), a driver for a device has
pc-bios/s390-ccw/virtio: Set missing status bits while initializing
According chapter "3.1.1 Driver Requirements: Device Initialization" of the Virtio specification (v1.1), a driver for a device has to set the ACKNOWLEDGE and DRIVER bits in the status field after resetting the device. The s390-ccw bios skipped these steps so far and seems like QEMU never cared. Anyway, it's better to follow the spec, so let's set these bits now in the right spots, too.
Message-Id: <20220704111903.62400-7-thuth@redhat.com> Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
show more ...
|
Revision tags: v7.2.2, v8.0.0, v8.0.0-rc4, v8.0.0-rc3, v7.2.1, v8.0.0-rc2, v8.0.0-rc1, v8.0.0-rc0, v7.2.0, v7.2.0-rc4, v7.2.0-rc3, v7.2.0-rc2, v7.2.0-rc1, v7.2.0-rc0, v7.1.0, v7.1.0-rc4, v7.1.0-rc3, v7.1.0-rc2, v7.1.0-rc1, v7.1.0-rc0 |
|
#
07082488 |
| 04-Jul-2022 |
Thomas Huth <thuth@redhat.com> |
pc-bios/s390-ccw/virtio: Beautify the code for reading virtqueue configuration
It looks nicer if we separate the run_ccw() from the IPL_assert() statement, and the error message should talk about "v
pc-bios/s390-ccw/virtio: Beautify the code for reading virtqueue configuration
It looks nicer if we separate the run_ccw() from the IPL_assert() statement, and the error message should talk about "virtio device" instead of "block device", since this code is nowadays used for non-block (i.e. network) devices, too.
Message-Id: <20220704111903.62400-9-thuth@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
show more ...
|
#
aa5c69ce |
| 04-Jul-2022 |
Thomas Huth <thuth@redhat.com> |
pc-bios/s390-ccw/virtio: Read device config after feature negotiation
Feature negotiation should be done first, since some fields in the config area can depend on the negotiated features and thus sh
pc-bios/s390-ccw/virtio: Read device config after feature negotiation
Feature negotiation should be done first, since some fields in the config area can depend on the negotiated features and thus should rather be read afterwards.
While we're at it, also adjust the error message here a little bit (the code is nowadays used for non-block virtio devices, too).
Message-Id: <20220704111903.62400-8-thuth@redhat.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
show more ...
|
#
175aa06a |
| 04-Jul-2022 |
Thomas Huth <thuth@redhat.com> |
pc-bios/s390-ccw/virtio: Set missing status bits while initializing
According chapter "3.1.1 Driver Requirements: Device Initialization" of the Virtio specification (v1.1), a driver for a device has
pc-bios/s390-ccw/virtio: Set missing status bits while initializing
According chapter "3.1.1 Driver Requirements: Device Initialization" of the Virtio specification (v1.1), a driver for a device has to set the ACKNOWLEDGE and DRIVER bits in the status field after resetting the device. The s390-ccw bios skipped these steps so far and seems like QEMU never cared. Anyway, it's better to follow the spec, so let's set these bits now in the right spots, too.
Message-Id: <20220704111903.62400-7-thuth@redhat.com> Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
show more ...
|
Revision tags: v7.2.2, v8.0.0, v8.0.0-rc4, v8.0.0-rc3, v7.2.1, v8.0.0-rc2, v8.0.0-rc1, v8.0.0-rc0, v7.2.0, v7.2.0-rc4, v7.2.0-rc3, v7.2.0-rc2, v7.2.0-rc1, v7.2.0-rc0, v7.1.0, v7.1.0-rc4, v7.1.0-rc3, v7.1.0-rc2, v7.1.0-rc1, v7.1.0-rc0 |
|
#
07082488 |
| 04-Jul-2022 |
Thomas Huth <thuth@redhat.com> |
pc-bios/s390-ccw/virtio: Beautify the code for reading virtqueue configuration
It looks nicer if we separate the run_ccw() from the IPL_assert() statement, and the error message should talk about "v
pc-bios/s390-ccw/virtio: Beautify the code for reading virtqueue configuration
It looks nicer if we separate the run_ccw() from the IPL_assert() statement, and the error message should talk about "virtio device" instead of "block device", since this code is nowadays used for non-block (i.e. network) devices, too.
Message-Id: <20220704111903.62400-9-thuth@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
show more ...
|
#
aa5c69ce |
| 04-Jul-2022 |
Thomas Huth <thuth@redhat.com> |
pc-bios/s390-ccw/virtio: Read device config after feature negotiation
Feature negotiation should be done first, since some fields in the config area can depend on the negotiated features and thus sh
pc-bios/s390-ccw/virtio: Read device config after feature negotiation
Feature negotiation should be done first, since some fields in the config area can depend on the negotiated features and thus should rather be read afterwards.
While we're at it, also adjust the error message here a little bit (the code is nowadays used for non-block virtio devices, too).
Message-Id: <20220704111903.62400-8-thuth@redhat.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
show more ...
|
#
175aa06a |
| 04-Jul-2022 |
Thomas Huth <thuth@redhat.com> |
pc-bios/s390-ccw/virtio: Set missing status bits while initializing
According chapter "3.1.1 Driver Requirements: Device Initialization" of the Virtio specification (v1.1), a driver for a device has
pc-bios/s390-ccw/virtio: Set missing status bits while initializing
According chapter "3.1.1 Driver Requirements: Device Initialization" of the Virtio specification (v1.1), a driver for a device has to set the ACKNOWLEDGE and DRIVER bits in the status field after resetting the device. The s390-ccw bios skipped these steps so far and seems like QEMU never cared. Anyway, it's better to follow the spec, so let's set these bits now in the right spots, too.
Message-Id: <20220704111903.62400-7-thuth@redhat.com> Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
show more ...
|
Revision tags: v7.0.0, v7.0.0-rc4, v7.0.0-rc3, v7.0.0-rc2, v7.0.0-rc1, v7.0.0-rc0, v6.1.1, v6.2.0, v6.2.0-rc4, v6.2.0-rc3, v6.2.0-rc2, v6.2.0-rc1, v6.2.0-rc0, v6.0.1, v6.1.0, v6.1.0-rc4, v6.1.0-rc3, v6.1.0-rc2, v6.1.0-rc1, v6.1.0-rc0 |
|
#
052b66e7 |
| 12-May-2021 |
Thomas Huth <thuth@redhat.com> |
pc-bios/s390-ccw: Fix inline assembly for older versions of Clang
Clang versions before v11.0 insist on having the %rX or %cX register names instead of just a number. Since our Travis-CI is currentl
pc-bios/s390-ccw: Fix inline assembly for older versions of Clang
Clang versions before v11.0 insist on having the %rX or %cX register names instead of just a number. Since our Travis-CI is currently still using Clang v6.0, we have to fix this to avoid failing jobs.
Message-Id: <20210512171550.476130-2-thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
show more ...
|
Revision tags: v6.0.0, v6.0.0-rc5, v6.0.0-rc4, v6.0.0-rc3, v6.0.0-rc2, v6.0.0-rc1, v6.0.0-rc0, v5.2.0, v5.2.0-rc4, v5.2.0-rc3, v5.2.0-rc2, v5.2.0-rc1, v5.2.0-rc0, v5.0.1, v5.1.0, v5.1.0-rc3, v5.1.0-rc2, v5.1.0-rc1, v5.1.0-rc0, v4.2.1 |
|
#
e70bc57b |
| 24-Jun-2020 |
Janosch Frank <frankja@linux.ibm.com> |
pc-bios: s390x: Consolidate timing functions into time.h
Let's consolidate timing related functions into one header.
Signed-off-by: Janosch Frank <frankja@linux.ibm.com> Acked-by: Thomas Huth <thut
pc-bios: s390x: Consolidate timing functions into time.h
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>
show more ...
|
Revision tags: v5.0.0, v5.0.0-rc4, v5.0.0-rc3, v5.0.0-rc2, v5.0.0-rc1, v5.0.0-rc0, v4.2.0, v4.2.0-rc5, v4.2.0-rc4, v4.2.0-rc3, v4.2.0-rc2, v4.1.1, v4.2.0-rc1, v4.2.0-rc0, v4.0.1, v3.1.1.1, v4.1.0, v4.1.0-rc5, v4.1.0-rc4, v3.1.1, v4.1.0-rc3, v4.1.0-rc2, v4.1.0-rc1, v4.1.0-rc0, v4.0.0, v4.0.0-rc4, v3.0.1, v4.0.0-rc3 |
|
#
3668cb7c |
| 04-Apr-2019 |
Jason J. Herne <jjherne@linux.ibm.com> |
s390-bios: Use control unit type to determine boot method
The boot method is different depending on which device type we are booting from. Let's examine the control unit type to determine if we're a
s390-bios: Use control unit type to determine boot method
The boot method is different depending on which device type we are booting from. Let's examine the control unit type to determine if we're a virtio device. We'll eventually add a case to check for a real dasd device here as well.
Since we have to call enable_subchannel() in main now, might as well remove that call from virtio.c : run_ccw(). This requires adding some additional enable_subchannel calls to not break calls to virtio_is_supported().
Signed-off-by: Jason J. Herne <jjherne@linux.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <1554388475-18329-14-git-send-email-jjherne@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
show more ...
|
#
9de6cbb1 |
| 04-Apr-2019 |
Jason J. Herne <jjherne@linux.ibm.com> |
s390-bios: Refactor virtio to run channel programs via cio
Now that we have a Channel I/O library let's modify virtio boot code to make use of it for running channel programs.
Signed-off-by: Jason
s390-bios: Refactor virtio to run channel programs via cio
Now that we have a Channel I/O library let's modify virtio boot code to make use of it for running channel programs.
Signed-off-by: Jason J. Herne <jjherne@linux.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Acked-by: Thomas Huth <thuth@redhat.com> Message-Id: <1554388475-18329-13-git-send-email-jjherne@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
show more ...
|
#
120d0410 |
| 04-Apr-2019 |
Jason J. Herne <jjherne@linux.ibm.com> |
s390-bios: Decouple channel i/o logic from virtio
Create a separate library for channel i/o related code. This decouples channel i/o operations from virtio and allows us to make use of them for the
s390-bios: Decouple channel i/o logic from virtio
Create a separate library for channel i/o related code. This decouples channel i/o operations from virtio and allows us to make use of them for the real dasd boot path.
Signed-off-by: Jason J. Herne <jjherne@linux.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <1554388475-18329-6-git-send-email-jjherne@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
show more ...
|