Hi,
On 5/13/19 3:05 PM, Christoph Hellwig wrote:
On Mon, May 06, 2019 at 09:54:30AM +0800, Lu Baolu wrote:
Agreed. I will prepare the next version simply without the optimization, so
the offset is not required.
For your changes in swiotlb, will you formalize them in patches or want
me to do
On Mon, May 06, 2019 at 09:54:30AM +0800, Lu Baolu wrote:
> Agreed. I will prepare the next version simply without the optimization, so
> the offset is not required.
>
> For your changes in swiotlb, will you formalize them in patches or want
> me to do this?
Please do it yourself given that you
Hi Christoph,
On 4/29/19 7:44 PM, Christoph Hellwig wrote:
On Mon, Apr 29, 2019 at 12:06:52PM +0100, Robin Murphy wrote:
From the reply up-thread I guess you're trying to include an optimisation
to only copy the head and tail of the buffer if it spans multiple pages,
and directly map the
Hi Robin,
On 4/30/19 5:53 PM, Robin Murphy wrote:
On 30/04/2019 03:02, Lu Baolu wrote:
Hi Robin,
On 4/29/19 7:06 PM, Robin Murphy wrote:
On 29/04/2019 06:10, Lu Baolu wrote:
Hi Christoph,
On 4/26/19 11:04 PM, Christoph Hellwig wrote:
On Thu, Apr 25, 2019 at 10:07:19AM +0800, Lu Baolu
On 30/04/2019 03:02, Lu Baolu wrote:
Hi Robin,
On 4/29/19 7:06 PM, Robin Murphy wrote:
On 29/04/2019 06:10, Lu Baolu wrote:
Hi Christoph,
On 4/26/19 11:04 PM, Christoph Hellwig wrote:
On Thu, Apr 25, 2019 at 10:07:19AM +0800, Lu Baolu wrote:
This is not VT-d specific. It's just how generic
Hi Robin,
On 4/29/19 7:06 PM, Robin Murphy wrote:
On 29/04/2019 06:10, Lu Baolu wrote:
Hi Christoph,
On 4/26/19 11:04 PM, Christoph Hellwig wrote:
On Thu, Apr 25, 2019 at 10:07:19AM +0800, Lu Baolu wrote:
This is not VT-d specific. It's just how generic IOMMU works.
Normally, IOMMU works
On Mon, Apr 29, 2019 at 12:06:52PM +0100, Robin Murphy wrote:
>
> From the reply up-thread I guess you're trying to include an optimisation
> to only copy the head and tail of the buffer if it spans multiple pages,
> and directly map the ones in the middle, but AFAICS that's going to tie you
>
On 29/04/2019 06:10, Lu Baolu wrote:
Hi Christoph,
On 4/26/19 11:04 PM, Christoph Hellwig wrote:
On Thu, Apr 25, 2019 at 10:07:19AM +0800, Lu Baolu wrote:
This is not VT-d specific. It's just how generic IOMMU works.
Normally, IOMMU works in paging mode. So if a driver issues DMA with
IOVA
Hi Christoph,
On 4/26/19 11:04 PM, Christoph Hellwig wrote:
On Thu, Apr 25, 2019 at 10:07:19AM +0800, Lu Baolu wrote:
This is not VT-d specific. It's just how generic IOMMU works.
Normally, IOMMU works in paging mode. So if a driver issues DMA with
IOVA 0x0123, IOMMU can remap it with a
On Thu, Apr 25, 2019 at 10:07:19AM +0800, Lu Baolu wrote:
> This is not VT-d specific. It's just how generic IOMMU works.
>
> Normally, IOMMU works in paging mode. So if a driver issues DMA with
> IOVA 0x0123, IOMMU can remap it with a physical address 0x0123.
> But we should never expect
Hi,
On 4/24/19 10:45 PM, Christoph Hellwig wrote:
On Tue, Apr 23, 2019 at 03:32:16PM +0800, Lu Baolu wrote:
When we add the bounce buffer between IOVA and physical buffer, the
bounced buffer must starts from the same offset in a page, otherwise,
IOMMU can't work here.
Why? Even with the odd
On Tue, Apr 23, 2019 at 03:32:16PM +0800, Lu Baolu wrote:
> When we add the bounce buffer between IOVA and physical buffer, the
> bounced buffer must starts from the same offset in a page, otherwise,
> IOMMU can't work here.
Why? Even with the odd hardware descriptors typical in Intel land that
Hi Christoph,
On 4/23/19 2:12 PM, Christoph Hellwig wrote:
On Tue, Apr 23, 2019 at 09:58:19AM +0800, Lu Baolu wrote:
554 for (i = 0; i < nslots; i++)
555 io_tlb_orig_addr[index+i] = orig_addr + (i <<
IO_TLB_SHIFT);
Could the tlb orig address set to
On Tue, Apr 23, 2019 at 09:58:19AM +0800, Lu Baolu wrote:
> 554 for (i = 0; i < nslots; i++)
> 555 io_tlb_orig_addr[index+i] = orig_addr + (i <<
> IO_TLB_SHIFT);
>
> Could the tlb orig address set to PAGE_ALIGN_DOWN(orig_addr)? We
> couldn't assume the bounce buffer just
Hi Christoph,
Thanks for reviewing my patches.
On 4/23/19 12:45 AM, Christoph Hellwig wrote:
I looked over your swiotlb modification and I don't think we really need
them. The only thing we really need is to split the size parameter to
swiotlb_tbl_map_single and swiotlb_tbl_unmap_single into
This moves slot allocation and free code into two common
functions in order to avoid code duplication. There's no
functional change.
Cc: Konrad Rzeszutek Wilk
Cc: Christoph Hellwig
Cc: Marek Szyprowski
Cc: Robin Murphy
Signed-off-by: Lu Baolu
---
kernel/dma/swiotlb.c | 72
16 matches
Mail list logo
