From: Joerg Roedel
The SWIOTLB implementation has a maximum size it can
allocate dma-handles for. This needs to be exported so that
device drivers don't try to allocate larger chunks.
This is especially important for block device drivers like
virtio-blk, that might do DMA through SWIOTLB.
From: Joerg Roedel
This function returns the maximum segment size for a single
dma transaction of a virtio device. The possible limit comes
from the SWIOTLB implementation in the Linux kernel, that
has an upper limit of (currently) 256kb of contiguous
memory it can map.
The functions return the
From: Joerg Roedel
Segments can't be larger than the maximum DMA allocation
size supported by virtio on the platform. Take that into
account when setting the maximum segment size for a block
device.
Signed-off-by: Joerg Roedel
---
drivers/block/virtio_blk.c | 10 ++
1 file changed, 6
Hi,
there is a problem with virtio-blk driven devices when
virtio-ring uses SWIOTLB through the DMA-API. This happens
for example in AMD-SEV enabled guests, where the guest RAM
is mostly encrypted and all emulated DMA has to happen
to/from the SWIOTLB aperture.
The problem is a limitation of the
Am 10.01.19 um 14:57 schrieb Christoph Hellwig:
On Thu, Jan 10, 2019 at 10:59:02AM +0100, Michel Dänzer wrote:
Hi Christoph,
https://bugs.freedesktop.org/109234 (please ignore comments #6-#9) was
bisected to your commit 55897af63091 "dma-direct: merge swiotlb_dma_ops
into the dma_direct
On Thu, Jan 10, 2019 at 02:44:30PM +0100, Joerg Roedel wrote:
> Hi,
>
> there is a problem with virtio-blk driven devices when
> virtio-ring uses SWIOTLB through the DMA-API. This happens
> for example in AMD-SEV enabled guests, where the guest RAM
> is mostly encrypted and all emulated DMA has
Hi Christoph,
On Thu, Jan 10, 2019 at 02:59:52PM +0100, Christoph Hellwig wrote:
> On Thu, Jan 10, 2019 at 02:44:30PM +0100, Joerg Roedel wrote:
> > The problem is a limitation of the SWIOTLB implementation,
> > which does not support allocations larger than 256kb. When
> > the virtio-blk driver
On Thu, Jan 10, 2019 at 10:59:02AM +0100, Michel Dänzer wrote:
>
> Hi Christoph,
>
>
> https://bugs.freedesktop.org/109234 (please ignore comments #6-#9) was
> bisected to your commit 55897af63091 "dma-direct: merge swiotlb_dma_ops
> into the dma_direct code". Any ideas?
>From the trace it
On Thu, Jan 10, 2019 at 03:00:31PM +0100, Christian König wrote:
>> From the trace it looks like we git the case where swiotlb tries
>> to copy back data from a bounce buffer, but hits a dangling or NULL
>> pointer. So a couple questions for the submitter:
>>
>> - does the system have more
Hi Robin, Drew,
On 12/19/18 2:18 PM, Andrew Jones wrote:
> On Wed, Dec 19, 2018 at 12:21:35PM +, Robin Murphy wrote:
>> On 18/12/2018 18:48, Andrew Jones wrote:
>>> The sum of dmaaddr and size may overflow, particularly considering
>>> there are cases where size will be U64_MAX.
>>
>> Only if
Hi Christoph,
https://bugs.freedesktop.org/109234 (please ignore comments #6-#9) was
bisected to your commit 55897af63091 "dma-direct: merge swiotlb_dma_ops
into the dma_direct code". Any ideas?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software
On Thu, 10 Jan 2019 at 14:57, Christoph Hellwig wrote:
>
> On Thu, Jan 10, 2019 at 10:59:02AM +0100, Michel Dänzer wrote:
> >
> > Hi Christoph,
> >
> >
> > https://bugs.freedesktop.org/109234 (please ignore comments #6-#9) was
> > bisected to your commit 55897af63091 "dma-direct: merge
On Thu, Jan 10, 2019 at 02:44:31PM +0100, Joerg Roedel wrote:
> From: Joerg Roedel
>
> The SWIOTLB implementation has a maximum size it can
> allocate dma-handles for. This needs to be exported so that
> device drivers don't try to allocate larger chunks.
>
> This is especially important for
On Thu, Jan 10, 2019 at 04:26:43PM +0100, Sibren Vasse wrote:
> On Thu, 10 Jan 2019 at 14:57, Christoph Hellwig wrote:
> >
> > On Thu, Jan 10, 2019 at 10:59:02AM +0100, Michel Dänzer wrote:
> > >
> > > Hi Christoph,
> > >
> > >
> > > https://bugs.freedesktop.org/109234 (please ignore comments
Let's skip it. There was another patch that would allocate a default 4MB
size if it there was an misue of swiotlb parameters.
On Mon, Jan 7, 2019, 4:07 AM Christoph Hellwig On Mon, Jan 07, 2019 at 04:46:51PM +0800, He Zhe wrote:
> > Kindly ping.
>
> Konrad, I'll pick this up through the DMA
On Thu, 10 Jan 2019 at 18:06, Konrad Rzeszutek Wilk
wrote:
>
> On Thu, Jan 10, 2019 at 04:26:43PM +0100, Sibren Vasse wrote:
> > On Thu, 10 Jan 2019 at 14:57, Christoph Hellwig wrote:
> > >
> > > On Thu, Jan 10, 2019 at 10:59:02AM +0100, Michel Dänzer wrote:
> > > >
> > > > Hi Christoph,
> > > >
On Thu, 10 Jan 2019 at 15:48, Christoph Hellwig wrote:
>
> On Thu, Jan 10, 2019 at 03:00:31PM +0100, Christian König wrote:
> >> From the trace it looks like we git the case where swiotlb tries
> >> to copy back data from a bounce buffer, but hits a dangling or NULL
> >> pointer. So a couple
On Tue, 8 Jan 2019 11:26:26 +0100
Eric Auger wrote:
> From: Jacob Pan
>
> Device faults detected by IOMMU can be reported outside IOMMU
> subsystem for further processing. This patch intends to provide
> a generic device fault data such that device drivers can be
> communicated with IOMMU
On 2019/1/10 下午9:44, Joerg Roedel wrote:
Hi,
there is a problem with virtio-blk driven devices when
virtio-ring uses SWIOTLB through the DMA-API. This happens
for example in AMD-SEV enabled guests, where the guest RAM
is mostly encrypted and all emulated DMA has to happen
to/from the SWIOTLB
Hi Christoph,
On 17/12/18 9:59 pm, Christoph Hellwig wrote:
On Sat, Dec 15, 2018 at 12:14:29AM +1000, Greg Ungerer wrote:
Yep, that is right. Certainly the MMU case is broken. Some noMMU cases work
by virtue of the SoC only having an instruction cache (the older V2 cores).
Is there a good an
From: Jacob Pan
VT-d Rev3.0 has made a few changes to the page request interface,
1. widened PRQ descriptor from 128 bits to 256 bits;
2. removed streaming response type;
3. introduced private data that requires page response even the
request is not last request in group (LPIG).
This is a
On 1/11/19 9:46 AM, He Zhe wrote:
>
> On 1/11/19 1:27 AM, Konrad Rzeszutek Wilk wrote:
>> Let's skip it. There was another patch that would allocate a default 4MB
>> size if it there was an misue of swiotlb parameters.
> But this patch mainly fixes a crash. Could you please point me to the
Next step: 891dcc1072f1fa27a83da920d88daff6ca08fc02 (powerpc/dma: remove
dma_nommu_dma_supported)
git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a
git checkout 891dcc1072f1fa27a83da920d88daff6ca08fc02
Output:
Note: checking out
On 1/11/19 1:27 AM, Konrad Rzeszutek Wilk wrote:
> Let's skip it. There was another patch that would allocate a default 4MB size
> if it there was an misue of swiotlb parameters.
But this patch mainly fixes a crash. Could you please point me to the patch you
mentioned?
Thanks,
Zhe
>
>
>
>
On Tue 08 Jan 03:18 PST 2019, Vivek Gautam wrote:
>
> On 1/8/2019 12:29 PM, Bjorn Andersson wrote:
> > On Thu 11 Oct 02:49 PDT 2018, Vivek Gautam wrote:
> >
> > > Add device node for arm,mmu-500 available on sdm845.
> > > This MMU-500 with single TCU and multiple TBU architecture
> > > is
25 matches
Mail list logo
