From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59340) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XPUHS-0008UT-Lx for qemu-devel@nongnu.org; Thu, 04 Sep 2014 06:28:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XPUHK-0007HU-Dv for qemu-devel@nongnu.org; Thu, 04 Sep 2014 06:28:42 -0400 Received: from e06smtp13.uk.ibm.com ([195.75.94.109]:48616) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XPUHK-0007HC-5C for qemu-devel@nongnu.org; Thu, 04 Sep 2014 06:28:34 -0400 Received: from /spool/local by e06smtp13.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 4 Sep 2014 11:28:30 +0100 Received: from b06cxnps4076.portsmouth.uk.ibm.com (d06relay13.portsmouth.uk.ibm.com [9.149.109.198]) by d06dlp01.portsmouth.uk.ibm.com (Postfix) with ESMTP id BA67B17D8056 for ; Thu, 4 Sep 2014 11:30:26 +0100 (BST) Received: from d06av11.portsmouth.uk.ibm.com (d06av11.portsmouth.uk.ibm.com [9.149.37.252]) by b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id s84ASSqg39190684 for ; Thu, 4 Sep 2014 10:28:28 GMT Received: from d06av11.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av11.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s84ASRBm029980 for ; Thu, 4 Sep 2014 04:28:28 -0600 Message-ID: <54083ECA.7040009@linux.vnet.ibm.com> Date: Thu, 04 Sep 2014 14:28:26 +0400 From: Ekaterina Tumanova MIME-Version: 1.0 References: <1406636839-11946-1-git-send-email-tumanova@linux.vnet.ibm.com> <1406636839-11946-5-git-send-email-tumanova@linux.vnet.ibm.com> <20140903154636.GB30664@stefanha-thinkpad.redhat.com> In-Reply-To: <20140903154636.GB30664@stefanha-thinkpad.redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 4/4] blocksize: add blkconf_blocksize call to all block devices List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: cornelia.huck@de.ibm.com, dahi@linux.vnet.ibm.com, Public KVM Mailing List , borntraeger@de.ibm.com On 09/03/2014 07:46 PM, Stefan Hajnoczi wrote: > On Tue, Jul 29, 2014 at 02:27:19PM +0200, Ekaterina Tumanova wrote: >> This patch add the blkconf_blocksize call to all >> devices, which use DEFINE_BLOCK_PROPERTIES. >> If the underlying driver function fails, blkconf_blocksizes >> will set blocksizes to default (512) value. >> >> Signed-off-by: Ekaterina Tumanova >> Reviewed-by: David Hildenbrand >> Acked-by: Cornelia Huck >> --- >> hw/block/nvme.c | 1 + >> hw/block/virtio-blk.c | 1 + >> hw/ide/qdev.c | 1 + >> hw/scsi/scsi-disk.c | 1 + >> hw/usb/dev-storage.c | 1 + >> include/hw/block/block.h | 4 ++-- >> 6 files changed, 7 insertions(+), 2 deletions(-) > > Wasn't this NACKed before on the grounds that it is likely to upset the > guest after live migration? QEMU doesn't automatically query the > storage because these parameters must be preserved across migration. > Sorry, haven't found this discussion in the mail list. Do you have a link? As far as I understand, the xxxxxx_init functions of the qemu block devices, which contain blkconf_blocksize calls, will be called again on the destination host before the guest is resumed. And since migration requests qemu to be brought on the same disk, the configuration will receive the same block size from the ioctl, as before. What do I miss? > The knowledge of these fields belongs in the management tool that > orchestrates migration, not QEMU. > For case of DASDs we need QEMU to know the underlying blocksize. And you mentioned in your review comment to the Einar's initial patch that you request this to be implemented for all architectures: "Detecting the underlying block size is a generally useful configuration option. This should not be s390-specific, so no need to rename DEFINE_BLOCK_PROPERTIES()." http://qemu.11.n7.nabble.com/Qemu-devel-PATCH-V3-0-2-hd-geometry-c-Integrate-HDIO-GETGEO-in-guessing-tt185124.html#none > If you want specific parameters, please put them in your guest > configuration. QEMU and libvirt support that. > > I'm concerned that this patch serious is likely to break things and > autodetection doesn't add much value since the management tool needs to > be aware of this information anyway. > Can you please explain what do you mean by "AUTOdetection"? Do you simply mean "detection by ioctl" or "detection performed without guest request"? > Stefan > Thanks!