From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56917) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XK5f4-0004lm-ND for qemu-devel@nongnu.org; Wed, 20 Aug 2014 09:10:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XK5ey-00052q-Dx for qemu-devel@nongnu.org; Wed, 20 Aug 2014 09:10:46 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36642) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XK5ey-00052l-3Q for qemu-devel@nongnu.org; Wed, 20 Aug 2014 09:10:40 -0400 Message-ID: <53F49E45.50102@redhat.com> Date: Wed, 20 Aug 2014 15:10:29 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1406636839-11946-1-git-send-email-tumanova@linux.vnet.ibm.com> <1406636839-11946-2-git-send-email-tumanova@linux.vnet.ibm.com> <53F459FD.2050108@redhat.com> <53F46BF2.6070705@de.ibm.com> In-Reply-To: <53F46BF2.6070705@de.ibm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/4] hd-geometry.c: Integrate HDIO_GETGEO in guessing for target-s390x List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Christian Borntraeger , Ekaterina Tumanova , Public KVM Mailing List Cc: cornelia.huck@de.ibm.com, dahi@linux.vnet.ibm.com Il 20/08/2014 11:35, Christian Borntraeger ha scritto: > On 20/08/14 10:19, Paolo Bonzini wrote: >> Il 29/07/2014 14:27, Ekaterina Tumanova ha scritto: >>> The new HDIO_GETGEO logic is required for two use cases: >>> a) Support for geometries of Direct Attached Storage Disks (DASD) >>> on s390x configured as backing of virtio block devices. >> >> Is this still relevant now that QEMU can emulate 512-byte sectors on top >> of host devices with 4k sectors? > > Yes, the geometry and the block size define the layout of the DASD disk format. This defines how the ibm disk layout partition table looks like. So partition detection of the IBM layout only works if values are correct. (see linux block/partitions/ibm.c. it needs these values to correctly locate the data structures). > > Furthermore, if you do an mkfs in the host and the guest sees a different block size all kind of strange things will happen when mounting, no? > >> >>> b) Support for FCP attached SCSI disks that do not yet have a >>> partition table. Without this patch, fdisk -l on the host would >>> return different results then fdisk -l in the guest. >> >> Can you provide an example? > > scsi disk in the host: > [root@host ~]# sfdisk -g /dev/disk/by-id/wwn-0x6005076305ffc1ae0000000000002593 > /dev/disk/by-id/wwn-0x6005076305ffc1ae0000000000002593: 1011 cylinders, 34 heads, 61 sectors/track > > same scsi disk in the guest as virtio-blk: > scsi disk in the guest: > [root@guest ~]# sfdisk -g /dev/disk/by-id/virtio-d20 > /dev/disk/by-id/virtio-d20: 2080 cylinders, 16 heads, 63 sectors/track > > 16/63 is currently hardcoded by QEMU, no matter what the host thinks. This gets overridden as soon as there is a partition table. > > command line was: > -drive file=/dev/disk/by-id/scsi-36005076305ffc1ae0000000000002593,if=none,id=drive-virtio-disk20,format=raw,serial=d20,cache=none,aio=native But this risks changing whenever you move data from a disk to another disk, or if you move a virtual DASD disk from physical DASD to physical SCSI. If s390 is so sensitive to the head count and number of sectors/track (on x86 everything is done with LBAs nowadays, even in the firmware), I think whatever management layer you use should always specify them explicitly. I'm not saying this patch shouldn't be included---but it should be treated as a handy thing for developers rather than as a definitive fix. Paolo