All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dongli Zhang <dongli.zhang@oracle.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: iommu@lists.linux-foundation.org, xen-devel@lists.xenproject.org,
	x86@kernel.org, linuxppc-dev@lists.ozlabs.org,
	virtualization@lists.linux-foundation.org,
	linux-kernel@vger.kernel.org, m.szyprowski@samsung.com,
	jgross@suse.com, tglx@linutronix.de, mingo@redhat.com,
	bp@alien8.de, dave.hansen@linux.intel.com,
	sstabellini@kernel.org, mpe@ellerman.id.au,
	konrad.wilk@oracle.com, mst@redhat.com, jasowang@redhat.com,
	joe.jin@oracle.com
Subject: Re: [PATCH RFC v1 4/7] swiotlb: to implement io_tlb_high_mem
Date: Fri, 10 Jun 2022 14:56:08 -0700	[thread overview]
Message-ID: <e6345c27-78fd-be72-9551-1d1fd5db37a4@oracle.com> (raw)
In-Reply-To: <YqF/sphJj6n+22Si@infradead.org>

Hi Christoph,

On 6/8/22 10:05 PM, Christoph Hellwig wrote:
> All this really needs to be hidden under the hood.
> 

Since this patch file has 200+ lines, would you please help clarify what does
'this' indicate?

The idea of this patch:

1. Convert the functions to initialize swiotlb into callee. The callee accepts
'true' or 'false' as arguments to indicate whether it is for default or new
swiotlb buffer, e.g., swiotlb_init_remap() into __swiotlb_init_remap().

2. At the caller side to decide if we are going to call the callee to create the
extra buffer.

Do you mean the callee if still *too high level* and all the
decision/allocation/initialization should be down at *lower level functions*?

E.g., if I re-work the "struct io_tlb_mem" to make the 64-bit buffer as the 2nd
array of io_tlb_mem->slots[32_or_64][index], the user will only notice it is the
default 'io_tlb_default_mem', but will not be able to know if it is allocated
from 32-bit or 64-bit buffer.

Thank you very much for the feedback.

Dongli Zhang

WARNING: multiple messages have this Message-ID (diff)
From: Dongli Zhang <dongli.zhang@oracle.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: jgross@suse.com, dave.hansen@linux.intel.com, mst@redhat.com,
	konrad.wilk@oracle.com, jasowang@redhat.com, x86@kernel.org,
	joe.jin@oracle.com, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	iommu@lists.linux-foundation.org, mingo@redhat.com, bp@alien8.de,
	sstabellini@kernel.org, xen-devel@lists.xenproject.org,
	tglx@linutronix.de, linuxppc-dev@lists.ozlabs.org,
	m.szyprowski@samsung.com
Subject: Re: [PATCH RFC v1 4/7] swiotlb: to implement io_tlb_high_mem
Date: Fri, 10 Jun 2022 14:56:08 -0700	[thread overview]
Message-ID: <e6345c27-78fd-be72-9551-1d1fd5db37a4@oracle.com> (raw)
In-Reply-To: <YqF/sphJj6n+22Si@infradead.org>

Hi Christoph,

On 6/8/22 10:05 PM, Christoph Hellwig wrote:
> All this really needs to be hidden under the hood.
> 

Since this patch file has 200+ lines, would you please help clarify what does
'this' indicate?

The idea of this patch:

1. Convert the functions to initialize swiotlb into callee. The callee accepts
'true' or 'false' as arguments to indicate whether it is for default or new
swiotlb buffer, e.g., swiotlb_init_remap() into __swiotlb_init_remap().

2. At the caller side to decide if we are going to call the callee to create the
extra buffer.

Do you mean the callee if still *too high level* and all the
decision/allocation/initialization should be down at *lower level functions*?

E.g., if I re-work the "struct io_tlb_mem" to make the 64-bit buffer as the 2nd
array of io_tlb_mem->slots[32_or_64][index], the user will only notice it is the
default 'io_tlb_default_mem', but will not be able to know if it is allocated
from 32-bit or 64-bit buffer.

Thank you very much for the feedback.

Dongli Zhang

WARNING: multiple messages have this Message-ID (diff)
From: Dongli Zhang <dongli.zhang@oracle.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: jgross@suse.com, dave.hansen@linux.intel.com, mst@redhat.com,
	konrad.wilk@oracle.com, mpe@ellerman.id.au, jasowang@redhat.com,
	x86@kernel.org, joe.jin@oracle.com, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	iommu@lists.linux-foundation.org, mingo@redhat.com, bp@alien8.de,
	sstabellini@kernel.org, xen-devel@lists.xenproject.org,
	tglx@linutronix.de, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH RFC v1 4/7] swiotlb: to implement io_tlb_high_mem
Date: Fri, 10 Jun 2022 14:56:08 -0700	[thread overview]
Message-ID: <e6345c27-78fd-be72-9551-1d1fd5db37a4@oracle.com> (raw)
In-Reply-To: <YqF/sphJj6n+22Si@infradead.org>

Hi Christoph,

On 6/8/22 10:05 PM, Christoph Hellwig wrote:
> All this really needs to be hidden under the hood.
> 

Since this patch file has 200+ lines, would you please help clarify what does
'this' indicate?

The idea of this patch:

1. Convert the functions to initialize swiotlb into callee. The callee accepts
'true' or 'false' as arguments to indicate whether it is for default or new
swiotlb buffer, e.g., swiotlb_init_remap() into __swiotlb_init_remap().

2. At the caller side to decide if we are going to call the callee to create the
extra buffer.

Do you mean the callee if still *too high level* and all the
decision/allocation/initialization should be down at *lower level functions*?

E.g., if I re-work the "struct io_tlb_mem" to make the 64-bit buffer as the 2nd
array of io_tlb_mem->slots[32_or_64][index], the user will only notice it is the
default 'io_tlb_default_mem', but will not be able to know if it is allocated
from 32-bit or 64-bit buffer.

Thank you very much for the feedback.

Dongli Zhang
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

WARNING: multiple messages have this Message-ID (diff)
From: Dongli Zhang <dongli.zhang@oracle.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: jgross@suse.com, dave.hansen@linux.intel.com, mst@redhat.com,
	konrad.wilk@oracle.com, mpe@ellerman.id.au, x86@kernel.org,
	joe.jin@oracle.com, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	iommu@lists.linux-foundation.org, mingo@redhat.com, bp@alien8.de,
	sstabellini@kernel.org, xen-devel@lists.xenproject.org,
	tglx@linutronix.de, linuxppc-dev@lists.ozlabs.org,
	m.szyprowski@samsung.com
Subject: Re: [PATCH RFC v1 4/7] swiotlb: to implement io_tlb_high_mem
Date: Fri, 10 Jun 2022 14:56:08 -0700	[thread overview]
Message-ID: <e6345c27-78fd-be72-9551-1d1fd5db37a4@oracle.com> (raw)
In-Reply-To: <YqF/sphJj6n+22Si@infradead.org>

Hi Christoph,

On 6/8/22 10:05 PM, Christoph Hellwig wrote:
> All this really needs to be hidden under the hood.
> 

Since this patch file has 200+ lines, would you please help clarify what does
'this' indicate?

The idea of this patch:

1. Convert the functions to initialize swiotlb into callee. The callee accepts
'true' or 'false' as arguments to indicate whether it is for default or new
swiotlb buffer, e.g., swiotlb_init_remap() into __swiotlb_init_remap().

2. At the caller side to decide if we are going to call the callee to create the
extra buffer.

Do you mean the callee if still *too high level* and all the
decision/allocation/initialization should be down at *lower level functions*?

E.g., if I re-work the "struct io_tlb_mem" to make the 64-bit buffer as the 2nd
array of io_tlb_mem->slots[32_or_64][index], the user will only notice it is the
default 'io_tlb_default_mem', but will not be able to know if it is allocated
from 32-bit or 64-bit buffer.

Thank you very much for the feedback.

Dongli Zhang
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

  reply	other threads:[~2022-06-10 21:57 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-09  0:55 [PATCH RFC v1 0/7] swiotlb: extra 64-bit buffer for dev->dma_io_tlb_mem Dongli Zhang
2022-06-09  0:55 ` Dongli Zhang
2022-06-09  0:55 ` Dongli Zhang
2022-06-09  0:55 ` Dongli Zhang
2022-06-09  0:55 ` [PATCH RFC v1 1/7] swiotlb: introduce the highmem swiotlb buffer Dongli Zhang
2022-06-09  0:55   ` Dongli Zhang
2022-06-09  0:55   ` Dongli Zhang
2022-06-09  0:55   ` Dongli Zhang
2022-06-09  5:04   ` Christoph Hellwig
2022-06-09  5:04     ` Christoph Hellwig
2022-06-09  5:04     ` Christoph Hellwig
2022-06-09  5:04     ` Christoph Hellwig
2022-06-09  0:55 ` [PATCH RFC v1 2/7] swiotlb: change the signature of remap function Dongli Zhang
2022-06-09  0:55   ` Dongli Zhang
2022-06-09  0:55   ` Dongli Zhang
2022-06-09  0:55   ` Dongli Zhang
2022-06-09  0:55 ` [PATCH RFC v1 3/7] swiotlb-xen: support highmem for xen specific code Dongli Zhang
2022-06-09  0:55   ` Dongli Zhang
2022-06-09  0:55   ` Dongli Zhang
2022-06-09  0:55   ` Dongli Zhang
2022-06-09  5:08   ` Christoph Hellwig
2022-06-09  5:08     ` Christoph Hellwig
2022-06-09  5:08     ` Christoph Hellwig
2022-06-09  5:08     ` Christoph Hellwig
2022-06-09  0:55 ` [PATCH RFC v1 4/7] swiotlb: to implement io_tlb_high_mem Dongli Zhang
2022-06-09  0:55   ` Dongli Zhang
2022-06-09  0:55   ` Dongli Zhang
2022-06-09  0:55   ` Dongli Zhang
2022-06-09  5:05   ` Christoph Hellwig
2022-06-09  5:05     ` Christoph Hellwig
2022-06-09  5:05     ` Christoph Hellwig
2022-06-09  5:05     ` Christoph Hellwig
2022-06-10 21:56     ` Dongli Zhang [this message]
2022-06-10 21:56       ` Dongli Zhang
2022-06-10 21:56       ` Dongli Zhang
2022-06-10 21:56       ` Dongli Zhang
2022-06-13  6:04       ` Christoph Hellwig
2022-06-13  6:04         ` Christoph Hellwig
2022-06-13  6:04         ` Christoph Hellwig
2022-06-13  6:04         ` Christoph Hellwig
2022-06-09  0:55 ` [PATCH RFC v1 5/7] swiotlb: add interface to set dev->dma_io_tlb_mem Dongli Zhang
2022-06-09  0:55   ` Dongli Zhang
2022-06-09  0:55   ` Dongli Zhang
2022-06-09  0:55   ` Dongli Zhang
2022-06-09  5:06   ` Christoph Hellwig
2022-06-09  5:06     ` Christoph Hellwig
2022-06-09  5:06     ` Christoph Hellwig
2022-06-09  5:06     ` Christoph Hellwig
2022-06-09  0:55 ` [PATCH RFC v1 6/7] virtio: use io_tlb_high_mem if it is active Dongli Zhang
2022-06-09  0:55   ` Dongli Zhang
2022-06-09  0:55   ` Dongli Zhang
2022-06-09  0:55   ` Dongli Zhang
2022-06-09  5:07   ` Christoph Hellwig
2022-06-09  5:07     ` Christoph Hellwig
2022-06-09  5:07     ` Christoph Hellwig
2022-06-09  5:07     ` Christoph Hellwig
2022-06-09  0:55 ` [PATCH RFC v1 7/7] swiotlb: fix the slot_addr() overflow Dongli Zhang
2022-06-09  0:55   ` Dongli Zhang
2022-06-09  0:55   ` Dongli Zhang
2022-06-09  0:55   ` Dongli Zhang
2022-06-09  5:07   ` Christoph Hellwig
2022-06-09  5:07     ` Christoph Hellwig
2022-06-09  5:07     ` Christoph Hellwig
2022-06-09  5:07     ` Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e6345c27-78fd-be72-9551-1d1fd5db37a4@oracle.com \
    --to=dongli.zhang@oracle.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=hch@infradead.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jasowang@redhat.com \
    --cc=jgross@suse.com \
    --cc=joe.jin@oracle.com \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=m.szyprowski@samsung.com \
    --cc=mingo@redhat.com \
    --cc=mpe@ellerman.id.au \
    --cc=mst@redhat.com \
    --cc=sstabellini@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=x86@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.