On 02.05.2012, at 17:57, Stefan Weinhuber <w...@linux.vnet.ibm.com> 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
>>>>>> 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
> 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 :).