|
From: | Avi Kivity |
Subject: | Re: [Qemu-devel] [PATCH] honor IDE_DMA_BUF_SECTORS |
Date: | Thu, 26 Mar 2009 20:32:28 +0200 |
User-agent: | Thunderbird 2.0.0.21 (X11/20090320) |
Samuel Thibault wrote:
Avi Kivity, le Thu 26 Mar 2009 14:58:55 +0200, a écrit :Samuel Thibault wrote:Avi Kivity, le Thu 26 Mar 2009 14:10:20 +0200, a écrit :I realize your use case will probably not trigger this, but it does indicate you're limiting at the wrong layer. It places the burden on all callers of block format drivers instead of centralizing it.Then it should be centralized in the block layer instead of placing the burden on all block format drivers ;)If other drivers need to do that, certainly.In our case the other driver is specific to Xen.
I'm confused. I can only count one driver which has limited dma size.
One thing for instance that still have been overlooked although patches have been sent is block-raw-posix' read/write_pread_aligned() that consider partial read/writes as an error. That's a bug.Right. Unrelated topic though?Nope. It's exactly the issue: read/write() may not be able to perform the whole operation in just one go, and qemu should continue in that case.
Oh, you're overloading block-raw-posix? Isn't it more natural for you to implement block-raw-xen-pv-block-frontend? You'd be able to use asynchronous requests instead of a thread pool (much like block-raw-linux-aio).
-- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.
[Prev in Thread] | Current Thread | [Next in Thread] |