qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Geometry and blocksize support for backing devices


From: Markus Armbruster
Subject: Re: [Qemu-devel] Geometry and blocksize support for backing devices
Date: Fri, 07 Nov 2014 16:58:26 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Christian Borntraeger <address@hidden> writes:

> Am 07.11.2014 10:17, schrieb Markus Armbruster:
>> Christian Borntraeger <address@hidden> writes:
[...]
>>> Now here comes my proposal:
>>> Markus statement brought up an idea of special casing DASDs support. We can
>>> call an ioctl BIODASDINFO on the block device that will only
>>> succeed if the host
>>> disk is really a dasd. We could enable the auto detection for that case.
>> 
>> If BIODASDINFO succeeds, QEMU uses that instead of making up device
>> geometry as described above.  Correct?
>> 
>> Let's spell out when exactly BIODASDINFO succeeds, to avoid
>> misunderstandings.  It does when the backend is a DASD (/dev/dasd*).
>> What about a partition on a DASD?  A file in a filesystem on a DASD?
>
> BIODASDINFO (we will propbably use BIODASDINFO2) will succeed only if
> the backend is backed by a dasd or its partitions. It will fail on
> other block devices and files on a dasd.
>
> Now: when passing in only a dasd partition we cannot do any sane thing
> with the dasd oddities inside the guest (e.g. creating dasd
> partitions, reading volume label or TOC etc.)
> So there is no need passing in geometry and block size. We could make
> the special case even stricter and check for start == 0 when doing the
> HDIO_GETGEO.
> So pass-through of geometry and block size is only performed if
> BIODASDINFO2 succeeds, and the GETGEO call indicates that this is not
> a partions by having start == 0.
>
> Makes sense?

Yes.  Thank you!

[...]



reply via email to

[Prev in Thread] Current Thread [Next in Thread]