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

[Alexander Graf]

On 02.05.2012, at 17:57, Stefan Weinhuber <address@hidden> wrote:

> 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?

We could add a parameter to the disk configuration like type=dasd (default 
would be type=auto) which tells the geometry detection code to assume a 3390. 
If type == auto, we try a dasd ioctl and if that works use type=dasd.

That way you could easily create a dump of the disk and get it working with a 
simple type=dasd. Later we could even add dasd disk label detection code which 
defaults type=auto to dasd if it finds one.

That way disk images should be as easy to use as real dasd devices :).


Alex