Re: [Qemu-devel] [PATCH 2/3] geometry detection: use HDIO_GETGEO

[Stefan Weinhuber <wein@linux.vnet.ibm.com>]

On 2012-05-02 16:27, Christian Borntraeger wrote:
> On 02/05/12 14:54, Alexander Graf wrote:
>> On 05/02/2012 01:38 PM, Paolo Bonzini wrote:
>>>> On 05/02/2012 01:26 PM, Paolo Bonzini wrote:
>>>>>> 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.
>>>>> True, but how do you exercise that code path with DASD geometry
>>>>> on !__s390__?
>>>> If we make things a flag for the guessing code, it should work just
>>>> as well with image files, right?
>>> Only when they're not blank. :)  I was only thinking of #ifdef __s390__
>>> for the call to HDIO_GETGEO.
>>
>> Well, if guessing is a function
>>
>>    guess_size(disk_size, block_size)
>>
>> then we would be able to do the same on an image file. Christian, would that work?
>
> I think that the geometry values can not always be guessed correctly based on
> block_size and disk_size.
>
> Stefan, can you clarify that?
>
> If we cannot reliably guess the geometry based on blocksize and size, I still think
> that we should use the host values, e.g. after checking that BIODASDINFO2 returns
> successfully.

If we know the device type (e.g. 3390) and the block_size, then we can 
compute the number of blocks per track. The number of tracks per 
cylinder is a given (15) and the number of cylinders can be computed 
from these numbers and the disk_size.

How do we get the device type? I think we could get away with 
restricting ECKD DASDs to type 3390, but even then, how would we 
distinguish an ECKD DASD from anything else, e.g. a SCSI device?

We could simply attempt the above cylinder calculation for every device 
and if we get a result without a remainder we just assume that we have a 
DASD. This could lead to false positives, but maybe that is acceptable?

Stefan Weinhuber