From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:38703) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SPXRc-0006ZM-P7 for qemu-devel@nongnu.org; Wed, 02 May 2012 07:10:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SPXRY-00019Q-1E for qemu-devel@nongnu.org; Wed, 02 May 2012 07:10:04 -0400 Received: from cantor2.suse.de ([195.135.220.15]:41693 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SPXRX-00019D-O8 for qemu-devel@nongnu.org; Wed, 02 May 2012 07:09:59 -0400 Message-ID: <4FA11606.2000306@suse.de> Date: Wed, 02 May 2012 13:09:58 +0200 From: Alexander Graf MIME-Version: 1.0 References: <1335448165-26174-1-git-send-email-borntraeger@de.ibm.com> <1335448165-26174-3-git-send-email-borntraeger@de.ibm.com> <4F9AC55D.3000904@redhat.com> <4FA10C20.7050005@de.ibm.com> In-Reply-To: <4FA10C20.7050005@de.ibm.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 2/3] geometry detection: use HDIO_GETGEO List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Christian Borntraeger Cc: Heinz Graalfs , qemu-devel , Jens Freimann , Cornelia Huck , Paolo Bonzini , Einar Lueck On 05/02/2012 12:27 PM, Christian Borntraeger wrote: > On 27/04/12 18:12, Paolo Bonzini wrote: >> Il 26/04/2012 15:49, Christian Borntraeger ha scritto: >>> +#ifdef __linux__ >>> + } else if (bdrv_ioctl(bs, HDIO_GETGEO,&geo) == 0) { >>> + *pcyls = geo.cylinders; >>> + *pheads = geo.heads; >>> + *psecs = geo.sectors; >>> + bdrv_set_geometry_hint(bs, *pcyls, *pheads, *psecs); >>> +#endif >> Perhaps you could instead move guess_disk_lchs to target-specific code, >> adding add this code to the s390-specific implementation and under >> #ifdef __s390__. For x86 it doesn't make much sense, because a disk's >> geometry most likely will be a wrong guess for the geometry that a guest >> (for guests that care at all about geometries). > Fine with me. We care about the geometry only for dasd devices, Even for FCP-based > SCSI devices on s390 the geometry is not relevant. So moving that part to > s390 specific code might make sense if nobody else needs that. > Is that the case? > Alex, would that be ok for you? As hinted in my other mail, I think the way to go would be to give a hint to the geometry code that we're running on a DASD disk. Then we can * Ask the host device if it can give us its geometry, if so, use it * Guess depending on the logical block size and everyone should be happy :). I would really like to have as little #ifdef TARGET_S390 code in QEMU. And #ifdef __s390__ is even worse, as it means we won't be able to execise that code path on other architectures. Alex