From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:42259) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TukfZ-0007Ai-Q3 for qemu-devel@nongnu.org; Mon, 14 Jan 2013 09:05:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TukfR-0006Qd-R2 for qemu-devel@nongnu.org; Mon, 14 Jan 2013 09:05:45 -0500 Received: from mx1.redhat.com ([209.132.183.28]:21531) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TukfR-0006QY-HV for qemu-devel@nongnu.org; Mon, 14 Jan 2013 09:05:37 -0500 From: Markus Armbruster References: <1357923660-35202-1-git-send-email-elelueck@linux.vnet.ibm.com> <1357923660-35202-2-git-send-email-elelueck@linux.vnet.ibm.com> Date: Mon, 14 Jan 2013 14:23:26 +0100 In-Reply-To: <1357923660-35202-2-git-send-email-elelueck@linux.vnet.ibm.com> (Einar Lueck's message of "Fri, 11 Jan 2013 18:01:00 +0100") Message-ID: <878v7v290x.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH V2] hd-geometry.c: Integrate HDIO_GETGEO in guessing List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Einar Lueck Cc: kwolf@redhat.com, aliguori@us.ibm.com, stefanha@gmail.com, agraf@suse.de, qemu-devel@nongnu.org, Christian Borntraeger , Jens Freimann , cornelia.huck@de.ibm.com, pbonzini@redhat.com Einar Lueck writes: > This patch extends the function hd_geometry_guess. If no geo could > be guessed via guess_disk_lchs, a new function called guess_disk_pchs is > called. The latter utilizes HDIO_GET_GEO ioctl to ask the underlying disk > for geometry. > If this is not successful (e.g. image files) geometry is derived > from the size of the disk (as before). > 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. > 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. I'm afraid this could mess up existing, working disks. Consider a disk where guess_disk_lchs() fails and HDIO_GETGEO succeeds. The old code arbitrarily picks a "standard" physical geometry then. Your code picks the one returned by HDIO_GETGEO. Unless the two geometries happen to lead to a compatible address translation, any guest that actually uses the translation now sees different disk contents, with predictably bad results. Can this happen? If no, why not?