From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1LmXJZ-0002Zm-Mm
	for qemu-devel@nongnu.org; Wed, 25 Mar 2009 13:54:57 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1LmXJU-0002XQ-Vl
	for qemu-devel@nongnu.org; Wed, 25 Mar 2009 13:54:57 -0400
Received: from [199.232.76.173] (port=57300 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1LmXJU-0002XK-O4
	for qemu-devel@nongnu.org; Wed, 25 Mar 2009 13:54:52 -0400
Received: from smtp02.citrix.com ([66.165.176.63]:59495)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1LmXJT-0008Jb-PX
	for qemu-devel@nongnu.org; Wed, 25 Mar 2009 13:54:51 -0400
Received: from [10.80.225.184] ([10.80.225.184])
	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id n2PHslfV030203
	for <qemu-devel@nongnu.org>; Wed, 25 Mar 2009 10:54:48 -0700
Message-ID: <49CA6E4A.4080408@eu.citrix.com>
Date: Wed, 25 Mar 2009 17:47:54 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH] honor IDE_DMA_BUF_SECTORS
References: <49CA3591.1010309@eu.citrix.com>	<49CA4C3D.1070705@redhat.com>	<49CA59AE.8060605@eu.citrix.com>	<49CA5F9F.5040203@redhat.com>
	<49CA60BA.5060704@eu.citrix.com>
In-Reply-To: <49CA60BA.5060704@eu.citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>

Stefano Stabellini wrote:

>> Anyway I think IDE_DMA_BUF_SECTORS was a qemu limitation and did not 
>> model real hardware behaviour.
>>
> 
> 
> Therefore I must assume that we expect qemu to be able to handle any
> kind of dma request coming from the guest, which at the moment is
> limited to 64K sectors, am I right?

I checked the ide driver in the kernel and it assumes that the max
sectors is either 256 or 64K depending on lba support, exactly as qemu does.


So now my question is: if I want to reduce the maximum dma request size
inside qemu, given that I must fill correctly the guest provided sg
list, is it OK to use IDE_DMA_BUF_SECTORS in dma_buf_prepare as I have
done in my patch?

I don't see any other possible solution, but if you have any other
suggestion you are welcome to let me know.