Re: [Xen-devel] Re: [Xen-changelog] Work aroudn swiotlb issue where a read-only host buffer is

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

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