From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH] honor IDE_DMA_BUF_SECTORS
Date: Thu, 26 Mar 2009 10:31:57 +0000 [thread overview]
Message-ID: <49CB599D.6000701@eu.citrix.com> (raw)
In-Reply-To: <49CB5793.4030006@redhat.com>
Avi Kivity wrote:
> Stefano Stabellini wrote:
>> 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.
>>
>
> Look at the DMA API (dma-helpers.c) which already knows how to split
> large dma requests. Splitting is controlled by
> cpu_physical_memory_map() (which I'm guessing is your real limitation),
> so you might want to look at that.
>
> The advantage of this approach is that it will apply to scsi and virtio
> once they are ported to use the DMA API.
>
>
Unfortunately that is not really helpful: after the split done by
cpu_physical_memory_map the iovector is converted in a buffer in
bdrv_aio_rw_vector and then the full length of the buffer is passed on
to the bdrv_aio_write\read for the dma operation.
I need a way to set a maximum limit for the total number of sectors in
the dma operation, much like blk_queue_max_phys_segments in the kernel.
This could also be useful to make sure that we don't allocate bounce
buffers bigger than a predetermined limit.
next prev parent reply other threads:[~2009-03-26 10:39 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-25 13:45 [Qemu-devel] [PATCH] honor IDE_DMA_BUF_SECTORS Stefano Stabellini
2009-03-25 15:22 ` Avi Kivity
2009-03-25 16:19 ` Stefano Stabellini
2009-03-25 16:45 ` Avi Kivity
2009-03-25 16:50 ` Stefano Stabellini
2009-03-25 17:47 ` Stefano Stabellini
2009-03-26 10:23 ` Avi Kivity
2009-03-26 10:31 ` Stefano Stabellini [this message]
2009-03-26 10:57 ` Avi Kivity
2009-03-26 11:45 ` Stefano Stabellini
2009-03-26 12:10 ` Avi Kivity
2009-03-26 12:28 ` Stefano Stabellini
2009-03-26 12:47 ` Samuel Thibault
2009-03-26 12:58 ` Avi Kivity
2009-03-26 15:30 ` Samuel Thibault
2009-03-26 18:32 ` Avi Kivity
2009-03-26 18:48 ` Samuel Thibault
2009-03-26 19:40 ` Avi Kivity
2009-03-26 23:18 ` Samuel Thibault
2009-03-27 9:52 ` Avi Kivity
2009-03-27 10:32 ` Samuel Thibault
2009-03-27 10:53 ` Avi Kivity
2009-03-27 13:45 ` Samuel Thibault
2009-03-26 22:42 ` Christoph Hellwig
2009-03-26 23:22 ` Samuel Thibault
2009-03-27 10:02 ` Avi Kivity
2009-03-27 10:36 ` Samuel Thibault
2009-03-27 10:58 ` Avi Kivity
2009-03-25 16:46 ` Samuel Thibault
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=49CB599D.6000701@eu.citrix.com \
--to=stefano.stabellini@eu.citrix.com \
--cc=qemu-devel@nongnu.org \
/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).