From: Christian Borntraeger <borntraeger@de.ibm.com>
To: Paolo Bonzini <pbonzini@redhat.com>,
Ekaterina Tumanova <tumanova@linux.vnet.ibm.com>,
Public KVM Mailing List <qemu-devel@nongnu.org>
Cc: cornelia.huck@de.ibm.com, dahi@linux.vnet.ibm.com,
Stefan Hajnoczi <stefanha@redhat.com>,
Kevin Wolf <kwolf@redhat.com>
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 [thread overview]
Message-ID: <53FAF204.2000108@de.ibm.com> (raw)
In-Reply-To: <53F49E45.50102@redhat.com>
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:
>> [root@host ~]# 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:
>> [root@guest ~]# 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 <mihajlov@linux.vnet.ibm.com>
AuthorDate: Wed Aug 29 17:48:30 2012 +0200
Commit: Eric Blake <eblake@redhat.com>
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 <mihajlov@linux.vnet.ibm.com>
commit 277a49bce73da908c965e466b03f5fc97f04cae1
Author: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
AuthorDate: Wed Aug 29 17:48:31 2012 +0200
Commit: Eric Blake <eblake@redhat.com>
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 <mihajlov@linux.vnet.ibm.com>
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
next prev parent reply other threads:[~2014-08-25 8:21 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-29 12:27 [Qemu-devel] [PATCH 0/4] Geometry and blocksize support for backing devices Ekaterina Tumanova
2014-07-29 12:27 ` [Qemu-devel] [PATCH 1/4] hd-geometry.c: Integrate HDIO_GETGEO in guessing for target-s390x Ekaterina Tumanova
2014-08-20 8:19 ` Paolo Bonzini
2014-08-20 9:35 ` Christian Borntraeger
2014-08-20 13:10 ` Paolo Bonzini
2014-08-25 8:21 ` Christian Borntraeger [this message]
2014-07-29 12:27 ` [Qemu-devel] [PATCH 2/4] blocksize: support auto-sensing of blocksizes Ekaterina Tumanova
2014-09-03 15:37 ` Stefan Hajnoczi
2014-07-29 12:27 ` [Qemu-devel] [PATCH 3/4] blocksize: Add driver method to get the blocksizes Ekaterina Tumanova
2014-07-29 12:27 ` [Qemu-devel] [PATCH 4/4] blocksize: add blkconf_blocksize call to all block devices Ekaterina Tumanova
2014-09-03 15:46 ` Stefan Hajnoczi
2014-09-04 10:28 ` Ekaterina Tumanova
2014-09-17 14:00 ` Stefan Hajnoczi
2014-09-04 14:15 ` Christian Borntraeger
2014-09-17 13:56 ` Stefan Hajnoczi
2014-07-29 12:37 ` [Qemu-devel] [PATCH 0/4] Geometry and blocksize support for backing devices Christian Borntraeger
2014-11-06 15:58 ` [Qemu-devel] " Christian Borntraeger
2014-11-06 17:24 ` Paolo Bonzini
2014-11-06 19:05 ` Christian Borntraeger
2014-11-07 9:17 ` Markus Armbruster
2014-11-07 9:48 ` Christian Borntraeger
2014-11-07 15:58 ` Markus Armbruster
2014-11-07 13:39 ` Ekaterina Tumanova
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53FAF204.2000108@de.ibm.com \
--to=borntraeger@de.ibm.com \
--cc=cornelia.huck@de.ibm.com \
--cc=dahi@linux.vnet.ibm.com \
--cc=kwolf@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
--cc=tumanova@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).