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

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Muli Ben-Yehuda
On Sat, Dec 17, 2005 at 12:28:06PM +0000, Xen patchbot -unstable wrote:
> # HG changeset patch
> # User [hidden email]
> # 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?)

Cheers,
Muli
--
Muli Ben-Yehuda
http://www.mulix.org | http://mulix.livejournal.com/


_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xensource.com/xen-devel
Reply | Threaded
Open this post in threaded view
|

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

Keir Fraser

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 [hidden email]
>> # 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
[hidden email]
http://lists.xensource.com/xen-devel