| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Re: [Xen-changelog] Work aroudn swiotlb issue where a re
On 17 Dec 2005, at 14:35, Muli Ben-Yehuda wrote:
On Sat, Dec 17, 2005 at 12:28:06PM +0000, Xen patchbot -unstable wrote:
# HG changeset patch
# User kaf24@xxxxxxxxxxxxxxxxxxxx
# Node ID b92ca87a2403d465e4d1087f8a7a43223b21bed8
# Parent 1509521c824efbae25bb953a2e2a49ab3f7fe7f4
Work aroudn swiotlb issue where a read-only host buffer is
mapped for DMA_BIDIRECTIONAL streaming access by certain
low-level drivers. This causes an unnecessary copy to the
host buffer that previously caused a fatal kernel page fault.
The fix (calling __copy_to_user on a kernelspace buffer) seems rather
awkward, and will probably make tools such as sparse faint in
horror. Wouldn't it make more sense to have the buffer mapped
read/write in the first place and/or fix the LLDD to not do
DMA_BIDIRECTIONAL? (I don't know which of these is correct; I suspect
the second?)
Option (a) is not a great fit with our blkdev device model, where a
frontend only grants the backend read access to a buffer that is to be
written to disc. In this case the backend cannot map the buffer for
read/write access (and I'd hate to have to change the blkif
split-driver protocol to work around a Linux driver oddity).
Option (b) is the 'morally correct' fix, but I see DMA_BIDIRECTIONAL is
used in a large number of scsi drivers, all of which probably ought to
be fixed to specify the correct single direction.
The current fix is a bit skanky, but it is commented and has basically
zero overhead. My main fear would be that it might mask genuine kernel
bugs, but I think that's unlikely.
-- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home