From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:33025)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1RIzzj-0000gS-BJ
	for qemu-devel@nongnu.org; Wed, 26 Oct 2011 05:42:00 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1RIzzi-0000Xr-Dy
	for qemu-devel@nongnu.org; Wed, 26 Oct 2011 05:41:59 -0400
Received: from mx1.redhat.com ([209.132.183.28]:56677)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1RIzzi-0000XM-6C
	for qemu-devel@nongnu.org; Wed, 26 Oct 2011 05:41:58 -0400
Message-ID: <4EA7D5E0.7070101@redhat.com>
Date: Wed, 26 Oct 2011 11:41:52 +0200
From: Paolo Bonzini <pbonzini@redhat.com>
MIME-Version: 1.0
References: <m3ty6yslb1.fsf@neno.neno> <j83ihr$ec5$1@dough.gmane.org>
	<4EA6ACFE.6090109@redhat.com> <4EA6B41B.3000903@codemonkey.ws>
	<4EA6C00B.3030701@redhat.com> <4EA6C25C.8000502@codemonkey.ws>
	<4EA7C1B8.9000903@redhat.com>
	<m3bot49m0j.fsf@blackfin.pond.sub.org>
In-Reply-To: <m3bot49m0j.fsf@blackfin.pond.sub.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] KVM call agenda for October 25
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Markus Armbruster <armbru@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>, qemu-devel@nongnu.org, kvm@vger.kernel.org

On 10/26/2011 10:48 AM, Markus Armbruster wrote:
> Sector size is a device property.
>
> If the user asks for a 4K sector disk, and the backend can't support
> that, we need to reject the configuration.  Just like we reject
> read-only backends for read/write disks.

Isn't it the other way round, i.e. the user asks for a 512-byte sector 
disk (i.e. the default) with cache=none but the disk has 4k sectors? 
We're basically saying "choose between NFS and migration if you have 4k 
sector disks but your guest doesn't support them".  Understandable 
perhaps, but not exactly kind, and virtualization is also about 
shielding from this kind of hardware dependency even at the cost of 
performance.  QEMU should just warn about performance degradations, 
erroring out would be a policy decision that should be up to management.

> It's okay to default device properties to some backend-dependent value,
> if that improves usability.

On the other hand, not all guests support 4k-sectors properly.

Paolo