1be5c7
From 115507e5e8b97993b50ea7b39d6d4bb493973e46 Mon Sep 17 00:00:00 2001
1be5c7
From: Thomas Huth <thuth@redhat.com>
1be5c7
Date: Fri, 5 Aug 2022 11:42:14 +0200
1be5c7
Subject: [PATCH 9/9] pc-bios/s390-ccw: Fix booting with logical block size <
1be5c7
 physical block size
1be5c7
1be5c7
RH-Author: Thomas Huth <thuth@redhat.com>
1be5c7
RH-MergeRequest: 207: pc-bios/s390-ccw: Fix booting with logical block size < physical block size
1be5c7
RH-Commit: [1/1] ab22832592e0a48277bf7aca1b941a1be79aeab6
1be5c7
RH-Bugzilla: 2112296
1be5c7
RH-Acked-by: Cornelia Huck <cohuck@redhat.com>
1be5c7
RH-Acked-by: David Hildenbrand <david@redhat.com>
1be5c7
RH-Acked-by: Claudio Imbrenda <None>
1be5c7
1be5c7
For accessing single blocks during boot, it's the logical block size that
1be5c7
matters. (Physical block sizes are rather interesting e.g. for creating
1be5c7
file systems with the correct alignment for speed reasons etc.).
1be5c7
So the s390-ccw bios has to use the logical block size for calculating
1be5c7
sector numbers during the boot phase, the "physical_block_exp" shift
1be5c7
value must not be taken into account. This change fixes the boot process
1be5c7
when the guest hast been installed on a disk where the logical block size
1be5c7
differs from the physical one, e.g. if the guest has been installed
1be5c7
like this:
1be5c7
1be5c7
 qemu-system-s390x -nographic -accel kvm -m 2G \
1be5c7
  -drive if=none,id=d1,file=fedora.iso,format=raw,media=cdrom \
1be5c7
  -device virtio-scsi -device scsi-cd,drive=d1 \
1be5c7
  -drive if=none,id=d2,file=test.qcow2,format=qcow2
1be5c7
  -device virtio-blk,drive=d2,physical_block_size=4096,logical_block_size=512
1be5c7
1be5c7
Linux correctly uses the logical block size of 512 for the installation,
1be5c7
but the s390-ccw bios tries to boot from a disk with 4096 block size so
1be5c7
far, as long as this patch has not been applied yet (well, it used to work
1be5c7
by accident in the past due to the virtio_assume_scsi() hack that used to
1be5c7
enforce 512 byte sectors on all virtio-block disks, but that hack has been
1be5c7
well removed in commit 5447de2619050a0a4d to fix other scenarios).
1be5c7
1be5c7
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2112296
1be5c7
Message-Id: <20220805094214.285223-1-thuth@redhat.com>
1be5c7
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
1be5c7
Reviewed-by: Eric Farman <farman@linux.ibm.com>
1be5c7
Signed-off-by: Thomas Huth <thuth@redhat.com>
1be5c7
(cherry picked from commit 393296de19650e1400ca265914cfdeb313725363)
1be5c7
---
1be5c7
 pc-bios/s390-ccw/virtio-blkdev.c | 2 +-
1be5c7
 1 file changed, 1 insertion(+), 1 deletion(-)
1be5c7
1be5c7
diff --git a/pc-bios/s390-ccw/virtio-blkdev.c b/pc-bios/s390-ccw/virtio-blkdev.c
1be5c7
index 8271c47296..794f99b42c 100644
1be5c7
--- a/pc-bios/s390-ccw/virtio-blkdev.c
1be5c7
+++ b/pc-bios/s390-ccw/virtio-blkdev.c
1be5c7
@@ -173,7 +173,7 @@ int virtio_get_block_size(void)
1be5c7
 
1be5c7
     switch (vdev->senseid.cu_model) {
1be5c7
     case VIRTIO_ID_BLOCK:
1be5c7
-        return vdev->config.blk.blk_size << vdev->config.blk.physical_block_exp;
1be5c7
+        return vdev->config.blk.blk_size;
1be5c7
     case VIRTIO_ID_SCSI:
1be5c7
         return vdev->scsi_block_size;
1be5c7
     }
1be5c7
-- 
1be5c7
2.31.1
1be5c7