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