History log of /qemu/pc-bios/s390-ccw/virtio.c (Results 1 – 25 of 60)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
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 ...


123