qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 1/4] hd-geometry.c: Integrate HDIO_GETGEO in gue


From: Christian Borntraeger
Subject: Re: [Qemu-devel] [PATCH 1/4] hd-geometry.c: Integrate HDIO_GETGEO in guessing for target-s390x
Date: Mon, 25 Aug 2014 10:21:24 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.0

On 20/08/14 15:10, Paolo Bonzini wrote:
> Il 20/08/2014 11:35, Christian Borntraeger ha scritto:
>> On 20/08/14 10:19, Paolo Bonzini wrote:
>>> Il 29/07/2014 14:27, Ekaterina Tumanova ha scritto:
>>>> 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.
>>>
>>> Is this still relevant now that QEMU can emulate 512-byte sectors on top
>>> of host devices with 4k sectors?
>>
>> Yes, the geometry and the block size define the layout of the DASD disk 
>> format. This defines how the ibm disk layout partition table looks like. So 
>> partition detection of the IBM layout only works if values are correct. (see 
>> linux block/partitions/ibm.c. it needs these values to correctly locate the 
>> data structures).
>>
>> Furthermore, if you do an mkfs in the host and the guest sees a different 
>> block size all kind of strange things will happen when mounting, no?
>>
>>>
>>>> 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.
>>>
>>> Can you provide an example?
>>
>> scsi disk in the host:
>> address@hidden ~]#  sfdisk -g 
>> /dev/disk/by-id/wwn-0x6005076305ffc1ae0000000000002593
>> /dev/disk/by-id/wwn-0x6005076305ffc1ae0000000000002593: 1011 cylinders, 34 
>> heads, 61 sectors/track
>>
>> same scsi disk in the guest as virtio-blk:
>> scsi disk in the guest:
>> address@hidden ~]# sfdisk -g /dev/disk/by-id/virtio-d20
>> /dev/disk/by-id/virtio-d20: 2080 cylinders, 16 heads, 63 sectors/track
>>
>> 16/63 is currently hardcoded by QEMU, no matter what the host thinks. This 
>> gets overridden as soon as there is a partition table.
>>
>> command line was:
>> -drive 
>> file=/dev/disk/by-id/scsi-36005076305ffc1ae0000000000002593,if=none,id=drive-virtio-disk20,format=raw,serial=d20,cache=none,aio=native
> 
> But this risks changing whenever you move data from a disk to another
> disk, or if you move a virtual DASD disk from physical DASD to physical
> SCSI.
> 
> If s390 is so sensitive to the head count and number of sectors/track
> (on x86 everything is done with LBAs nowadays, even in the firmware), I
> think whatever management layer you use should always specify them
> explicitly.

Only the DASD disks are so sensitive. The SCSI geometry is just a cosmetic 
thing, but it doesnt hurt. So for anything that comes via FCP SCSI we dont have 
a series issue besides the cosmetic thing. (Well, unless you have a storage 
server with 4k scsi disks, then it also becomes an issue on x86 - already seen 
on Flash Systems and other storage servers).
> 
> I'm not saying this patch shouldn't be included---but it should be
> treated as a handy thing for developers rather than as a definitive fix.

Yes. I would even suggest, that for image files you better use a SCSI disk 
image (which then has the normal partition layout as x86). 
Of course, there are reasons to have image files to hold DASD images, but then 
you have to manually specify geo/ss. In fact, libvirt always supported to 
specify the geometry and Viktor from our team did the sector size support in 
libvirt with:

commit 5cc50ad7a4e139261079a5848859c84cab3b0c7c
Author:     Viktor Mihajlovski <address@hidden>
AuthorDate: Wed Aug 29 17:48:30 2012 +0200
Commit:     Eric Blake <address@hidden>
CommitDate: Fri Aug 31 11:27:27 2012 -0700

    conf: Support for Block Device IO Limits
    
    Introducing a new iolimits element allowing to override certain
    properties of a guest block device like the physical and logical
    block size.
    This can be useful for platforms with 'non-standard' disk formats
    like S390 DASD with its 4K block size.
    
    Signed-off-by: Viktor Mihajlovski <address@hidden>


commit 277a49bce73da908c965e466b03f5fc97f04cae1
Author:     Viktor Mihajlovski <address@hidden>
AuthorDate: Wed Aug 29 17:48:31 2012 +0200
Commit:     Eric Blake <address@hidden>
CommitDate: Fri Aug 31 11:27:47 2012 -0700

    qemu: Support for Block Device IO Limits.
    
    Implementation of iolimits for the qemu driver with
    capability probing for block size attribute and
    command line generation for block sizes.
    Including testcase for qemuxml2argvtest.
    
    Signed-off-by: Viktor Mihajlovski <address@hidden>

some time ago.

So this detection is mostly important for DASD disk passthrough as the defaults 
are plainly wrong for those disks. (Under LPAR and z/VM the disks work out of 
the box, so a proper detection really helps).
As far as I can see the patches only affect disks, that are "raw" or 
"host_device". So it would be good, if Kevin and Stefan could take a look at 
the overall design. If they/you come up with a totally different approach, that 
is also fine.
Kate was away last week, so hopefully she can continue to drive the discussion 
with you folks, when she is back.

Christian




reply via email to

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