Blame SOURCES/kvm-pc-bios-s390-ccw-Fix-booting-with-logical-block-size.patch

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