search for: vmalloc_to_pag

...f our workarounds are hideous -- allocate 4 bytes with kmalloc because we can't DMA onto the stack any more?). We already have a few places which do handle sgs of vmalloced addresses, such as the nx crypto driver: if (is_vmalloc_addr(start_addr)) sg_addr = page_to_phys(vmalloc_to_page(start_addr)) + offset_in_page(sg_addr); else sg_addr = __pa(sg_addr); and videobuf: pg = vmalloc_to_page(virt); if (NULL == pg) goto err; BUG_ON(page_to_pfn(pg) >= (1 <...

...f our workarounds are hideous -- allocate 4 bytes with kmalloc because we can't DMA onto the stack any more?). We already have a few places which do handle sgs of vmalloced addresses, such as the nx crypto driver: if (is_vmalloc_addr(start_addr)) sg_addr = page_to_phys(vmalloc_to_page(start_addr)) + offset_in_page(sg_addr); else sg_addr = __pa(sg_addr); and videobuf: pg = vmalloc_to_page(virt); if (NULL == pg) goto err; BUG_ON(page_to_pfn(pg) >= (1 <...

...eous -- allocate 4 bytes with kmalloc because we can't > DMA onto the stack any more?). We already have a few places which do > handle sgs of vmalloced addresses, such as the nx crypto driver: > > if (is_vmalloc_addr(start_addr)) > sg_addr = page_to_phys(vmalloc_to_page(start_addr)) > + offset_in_page(sg_addr); > else > sg_addr = __pa(sg_addr); > > and videobuf: > > pg = vmalloc_to_page(virt); > if (NULL == pg) > goto err; >...

...as concerned that > some other usage in the future might not have that guarantee. The vmalloc_to_sg call is wrapped into "if (is_vmalloc())", so this should not be a problem. > > sg_alloc_table_from_pages() does alot of what you need, you just need a > > small loop around vmalloc_to_page() create a struct page array > > beforehand. > > That feels like an extra allocation when under memory pressure and > more work, to not gain much -- there still needs to be a function that > iterates through all the pages. But I don't feel super strongly about > it and c...

...ct page *pg; + + *sg_ents = 0; + + sgt = kmalloc(sizeof(*sgt), GFP_KERNEL); + if (!sgt) + return NULL; + + nents = DIV_ROUND_UP(size, PAGE_SIZE) + 1; + ret = sg_alloc_table(sgt, nents, GFP_KERNEL); + if (ret) { + kfree(sgt); + return NULL; + } + + for_each_sg(sgt->sgl, sg, nents, i) { + pg = vmalloc_to_page(data); + if (!pg) { + sg_free_table(sgt); + kfree(sgt); + return NULL; + } + + s = rest_of_page(data); + if (s > size) + s = size; + + sg_set_page(sg, pg, s, offset_in_page(data)); + + size -= s; + data += s; + *sg_ents += 1; + + if (size) { + sg_unmark_end(sg); + } else { +...

...ct page *pg; + + *sg_ents = 0; + + sgt = kmalloc(sizeof(*sgt), GFP_KERNEL); + if (!sgt) + return NULL; + + nents = DIV_ROUND_UP(size, PAGE_SIZE) + 1; + ret = sg_alloc_table(sgt, nents, GFP_KERNEL); + if (ret) { + kfree(sgt); + return NULL; + } + + for_each_sg(sgt->sgl, sg, nents, i) { + pg = vmalloc_to_page(data); + if (!pg) { + sg_free_table(sgt); + kfree(sgt); + return NULL; + } + + s = rest_of_page(data); + if (s > size) + s = size; + + sg_set_page(sg, pg, s, offset_in_page(data)); + + size -= s; + data += s; + *sg_ents += 1; + + if (size) { + sg_unmark_end(sg); + } else { +...

...virtual address in > > vmalloc area. Then kernel panic. > > > > I must be missing something. Maybe it is because it has to do with RPMesg? > > I think it's an RPMesg bug, yes rpmsg bug is another issue, it should not use dma_alloc_coherent for reserved area, and use vmalloc_to_page. Anyway here using dma api will also trigger issue. > > > > > > > > > You might have noticed that I missed one possible case above: > > > > > > Xen/ARM DomU :-) > > > > > > > > > > > > Xen/ARM domUs don't need...

...virtual address in > > vmalloc area. Then kernel panic. > > > > I must be missing something. Maybe it is because it has to do with RPMesg? > > I think it's an RPMesg bug, yes rpmsg bug is another issue, it should not use dma_alloc_coherent for reserved area, and use vmalloc_to_page. Anyway here using dma api will also trigger issue. > > > > > > > > > You might have noticed that I missed one possible case above: > > > > > > Xen/ARM DomU :-) > > > > > > > > > > > > Xen/ARM domUs don't need...

...ck_irq(&vmci_dev_spinlock); vmci_dev_g = vmci_dev; + vmci_pdev = pdev; spin_unlock_irq(&vmci_dev_spinlock); /* @@ -553,9 +558,8 @@ static int vmci_guest_probe_device(struct pci_dev *pdev, * used. */ if (capabilities & VMCI_CAPS_NOTIFICATIONS) { - struct page *page = - vmalloc_to_page(vmci_dev->notification_bitmap); - unsigned long bitmap_ppn = page_to_pfn(page); + unsigned long bitmap_ppn = + vmci_dev->notification_base >> PAGE_SHIFT; if (!vmci_dbell_register_notification_bitmap(bitmap_ppn)) { dev_warn(&pdev->dev, "VMCI device unable to...

...NEL); > + if (!sgt) > + return NULL; > + > + nents = DIV_ROUND_UP(size, PAGE_SIZE) + 1; Why +1? > + ret = sg_alloc_table(sgt, nents, GFP_KERNEL); > + if (ret) { > + kfree(sgt); > + return NULL; > + } > + > + for_each_sg(sgt->sgl, sg, nents, i) { > + pg = vmalloc_to_page(data); > + if (!pg) { > + sg_free_table(sgt); > + kfree(sgt); > + return NULL; > + } > + > + s = rest_of_page(data); > + if (s > size) > + s = size; vmalloc memory is page aligned, so: s = min(PAGE_SIZE, size); > + sg_set_page(sg, pg, s, offset_in...

...lloc area. Then kernel panic. > > > > > > I must be missing something. Maybe it is because it has to do with RPMesg? > > > > I think it's an RPMesg bug, yes > > rpmsg bug is another issue, it should not use dma_alloc_coherent for reserved area, > and use vmalloc_to_page. > > Anyway here using dma api will also trigger issue. Is the stack trace above for the RPMesg issue or for the Trusty issue? If it is the stack trace for RPMesg, can you also post the Trusty stack trace? Or are they indentical?

...t; + void *src, *dst; > + > + /* > + * Order is important here. We must enable the hypercall page > + * so it is populated with code, then copy the code to an > + * executable page. > + */ > + wrmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64); > + > + pg = vmalloc_to_page(hv_hypercall_pg); > + dst = kmap(pg); > + src = memremap(hypercall_msr.guest_physical_address << PAGE_SHIFT, PAGE_SIZE, > + MEMREMAP_WB); memremap() can fail... > + memcpy(dst, src, PAGE_SIZE); > + memunmap(src); > + kunmap(pg); > + } else { > + hypercall_m...

...ed long pfn = vmalloc_to_pfn((void *)(x->buffer_addr+recv_offset*PAGE_SIZE)); printk(KERN_INFO "PFN 1 : %lu\n", pfn); // The returned PFN is "0", it''s therefore useless if(pfn_valid(pfn)){ printk(KERN_INFO "PFN 1 est valide\n"); } struct page * shPage = vmalloc_to_page((void *)(x->buffer_addr+recv_offset*PAGE_SIZE)); if(!page_count(shPage)){ printk(KERN_INFO "Error in page_count\n"); // I get a page, but the function page_count fails } I also tried to apply the operation >> PAGE_SHIFT to "manually" get the PFN but the PFN I get...

On Wed, 18 Apr 2018, David Miller wrote: > From: Mikulas Patocka <mpatocka at redhat.com> > Date: Wed, 18 Apr 2018 12:44:25 -0400 (EDT) > > > The structure net_device is followed by arbitrary driver-specific data > > (accessible with the function netdev_priv). And for virtio-net, these > > driver-specific data must be in DMA memory. > > And we are saying

...der is important here. We must enable the hypercall page >> > + * so it is populated with code, then copy the code to an >> > + * executable page. >> > + */ >> > + wrmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64); >> > + >> > + pg = vmalloc_to_page(hv_hypercall_pg); >> > + dst = kmap(pg); >> > + src = memremap(hypercall_msr.guest_physical_address << PAGE_SHIFT, PAGE_SIZE, >> > + MEMREMAP_WB); >> >> memremap() can fail... > > And we don't care here, if it fails, we would rather it p...

This patchset adds support for virtual IOMMU to the VMCI module. We switch to DMA consistent mappings for queuepair and doorbell pages that are passed to the device, which allows the module to work in the presence of vIOMMU/VT-d. Andy King (2): VMCI: Remove non-blocking/pinned queuepair support VMCI: Add support for virtual IOMMU drivers/misc/vmw_vmci/vmci_driver.c | 2 +-

This patchset adds support for virtual IOMMU to the VMCI module. We switch to DMA consistent mappings for queuepair and doorbell pages that are passed to the device, which allows the module to work in the presence of vIOMMU/VT-d. Andy King (2): VMCI: Remove non-blocking/pinned queuepair support VMCI: Add support for virtual IOMMU drivers/misc/vmw_vmci/vmci_driver.c | 2 +-

...ge >> >> > + * so it is populated with code, then copy the code to an >> >> > + * executable page. >> >> > + */ >> >> > + wrmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64); >> >> > + >> >> > + pg = vmalloc_to_page(hv_hypercall_pg); >> >> > + dst = kmap(pg); >> >> > + src = memremap(hypercall_msr.guest_physical_address << PAGE_SHIFT, PAGE_SIZE, >> >> > + MEMREMAP_WB); >> >> >> >> memremap() can fail... >> > >> &gt...

This patchset adds support for virtual IOMMU to the VMCI module. We switch to DMA consistent mappings for queuepair and doorbell pages that are passed to the device, which allows the module to work in the presence of vIOMMU/VT-d. Andy King (2): VMCI: Remove non-blocking/pinned queuepair support VMCI: Add support for virtual IOMMU drivers/misc/vmw_vmci/vmci_driver.c | 2 +-

This patchset adds support for virtual IOMMU to the VMCI module. We switch to DMA consistent mappings for queuepair and doorbell pages that are passed to the device, which allows the module to work in the presence of vIOMMU/VT-d. Andy King (2): VMCI: Remove non-blocking/pinned queuepair support VMCI: Add support for virtual IOMMU drivers/misc/vmw_vmci/vmci_driver.c | 2 +-