Re: [Qemu-devel] [PATCH V2] hd-geometry.c: Integrate HDIO_GETGEO in guessing

[Markus Armbruster]

Einar Lueck <address@hidden> writes:

> On 01/14/2013 02:23 PM, Markus Armbruster wrote:
>> Einar Lueck <address@hidden> 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?
>>
>
> You are right. There may be such cases. Thus, I see two options:
> a) making this code portion platform specific (s390x)
> b) introduction of a a command line option to force reconsideration of
> HDIO_GETGEO
> My impression is, that the value of b) is limited to s390x and
> therefore a) is the way to go.

No objection from me.