Re: getting the console output for s390 cdrom-test?

[Peter Maydell <peter.maydell@linaro.org>]

On Mon, 8 Feb 2021 at 11:34, Thomas Huth <thuth@redhat.com> wrote:
> Looks like the SCSI controller returned VIRTIO_SCSI_S_FAILURE instead of the
> expected VIRTIO_SCSI_S_BAD_TARGET here (see virtio_scsi_locate_device() in
> pc-bios/s390-ccw/virtio-scsi.c).
>
> The question is: How could that happen? If I get hw/scsi/virtio-scsi.c
> right, this is only set by virtio_scsi_fail_cmd_req(), i.e. it only happens
> if virtio_scsi_parse_req() returned -ENOTSUP ... which indicates that there
> was something wrong with the VirtIOSCSIReq request?

Yes, virtio_scsi_parse_req() returns ENOTSUP because it
fails the "if (out_size && in_size)" test.

I am becoming somewhat suspicious that the s390-ccw BIOS's
implementation of virtio is not putting in sufficient barriers,
and so if you get unlucky then the QEMU thread sees an inconsistent
view of the in-memory virtio data structures. For instance,
the virtio spec says you must have a memory barrier after
writing the available ring entries and before incrementing the
available index, but pc-bios/s390-ccw/virtio.c:vring_send_buf()
has no kind of enforcement of ordering between these two steps.

Linux's arch/s390/include/asm/barrier.h suggests s390 needs real
CPU barrier insns here; even if it didn't you would at least want
enough of a compiler-barrier to tell the compiler not to try to
reorder anything past it.

thanks
-- PMM