search for: swiotlb_alloc

In the trace below, swiotlb_alloc() is called with __GFP_NOWARN, it ors attrs with DMA_ATTR_NO_WARN and passes it to swiotlb_alloc_buffer(), which does NOT pass it on to swiotlb_tbl_map_single(), leading to an ever repeating warning that the caller of swiotlb_alloc() explicitly asked to be squelched. Pass the caller's request...

...+ if (1 || pool->type & IS_HUGE) > attrs = DMA_ATTR_NO_WARN; > > vaddr = dma_alloc_attrs(pool->dev, pool->size, &d_page->dma, While IS_HUGE is indeed false on my box, it just doesn't matter, because when we get to either the old or the new alloc(), it calls swiotlb_alloc_buffer(), which drops attrs passed to it on the floor, making it unlikely that alloc() caller wishes are granted. -Mike

...s appropriate Reported-by: kbuild test robot <lkp at intel.com> All errors (new ones prefixed by >>): In file included from drivers/gpu/drm/i915/i915_scatterlist.h:12:0, from drivers/gpu/drm/i915/i915_scatterlist.c:7: include/linux/swiotlb.h: In function 'swiotlb_alloc': >> include/linux/swiotlb.h:231:9: error: 'DMA_MAPPING_ERROR' undeclared (first use in this function); did you mean 'APM_NO_ERROR'? return DMA_MAPPING_ERROR; ^~~~~~~~~~~~~~~~~ APM_NO_ERROR include/linux/swiotlb.h:231:9: note: each undeclare...

...N=9.3.0 make.cross ARCH=sh If you fix the issue, kindly add following tag as appropriate Reported-by: kbuild test robot <lkp at intel.com> All warnings (new ones prefixed by >>): In file included from drivers/virtio/virtio_bounce.c:13: include/linux/swiotlb.h: In function 'swiotlb_alloc': include/linux/swiotlb.h:234:9: error: 'DMA_MAPPING_ERROR' undeclared (first use in this function) 234 | return DMA_MAPPING_ERROR; | ^~~~~~~~~~~~~~~~~ include/linux/swiotlb.h:234:9: note: each undeclared identifier is reported only once for each function it...

...on failed, size=2097152 [ 6253.341539] CPU: 2 PID: 3740 Comm: Xorg Kdump: loaded Tainted: G E 4.16.0.gf8cf2f1-default #687 [ 6253.341541] Hardware name: MEDION MS-7848/MS-7848, BIOS M7848W08.20C 09/23/2013 [ 6253.341543] Call Trace: [ 6253.341553] dump_stack+0x78/0xb3 [ 6253.341559] swiotlb_alloc+0x134/0x170 [ 6253.341567] ttm_dma_pool_alloc_new_pages+0x161/0x3c0 [ttm] [ 6253.341574] ttm_dma_pool_get_pages+0xe0/0x1c0 [ttm] [ 6253.341580] ttm_dma_populate+0x250/0x310 [ttm] [ 6253.341586] ttm_tt_populate+0x28/0x70 [ttm] [ 6253.341591] ttm_tt_bind+0x26/0x60 [ttm] [ 6253.341596] ttm_bo_ha...

...+#define VIRTIO_MAX_BOUNCE_SIZE (16*4096) > + > +static void *virtio_alloc_coherent(struct device *dev, size_t size, > + dma_addr_t *dma_handle, gfp_t gfp_flags, unsigned long attrs) > +{ > + phys_addr_t addr; > + > + if (!virtio_pool) > + return NULL; > + > + addr = swiotlb_alloc(virtio_pool, size, bounce_buf_paddr, ULONG_MAX); > + if (addr == DMA_MAPPING_ERROR) > + return NULL; > + > + *dma_handle = (addr - bounce_buf_paddr); > + > + return bounce_buf_vaddr + (addr - bounce_buf_paddr); > +} > + > +static void virtio_free_coherent(struct device *...

Hi Ingo, Here''s the chunk of patches to add Xen Dom0 support (it''s probably worth creating a new xen/dom0 topic branch for it). A dom0 Xen domain is basically the same as a normal domU domain, but it has extra privileges to directly access hardware. There are two issues to deal with: - translating to and from the domain''s pseudo-physical addresses and real machine

Hi all, Here''s a work in progress series whcih does a partial revert of the previous swiotlb changes, and does a partial replacement with Becky Bruce''s series. The most important difference is Becky''s use of phys_addr_t rather than page+offset to represent arbitrary pages. This turns out to be simpler. I didn''t replicate the map_single_page changes, since