On Wed, May 17, 2023 at 01:27:48PM +0200, Petr Tesařík wrote:
> On Wed, 17 May 2023 08:35:10 +0200
> Petr Tesařík wrote:
> > Anyway, my greatest objection to allocating additional swiotlb chunks is
> > that _all_ of them must be searched to determine that the physical
> > address does _not_ belong
On Tue, 23 May 2023 10:54:11 +0100
Catalin Marinas wrote:
> On Wed, May 17, 2023 at 01:27:48PM +0200, Petr Tesařík wrote:
> > On Wed, 17 May 2023 08:35:10 +0200
> > Petr Tesařík wrote:
> > > Anyway, my greatest objection to allocating additional swiotlb chunks is
> > > that _all_ of them must
On Wed, May 17, 2023 at 11:58:21AM +0200, Petr Tesařík wrote:
> On Wed, 17 May 2023 10:41:19 +0100
> Catalin Marinas wrote:
> > On Wed, May 17, 2023 at 08:56:53AM +0200, Christoph Hellwig wrote:
> > > Just thinking out loud:
> > >
> > > - what if we always way overallocate the swiotlb buffer
> >
On Wed, May 17, 2023 at 08:56:53AM +0200, Christoph Hellwig wrote:
> Just thinking out loud:
>
> - what if we always way overallocate the swiotlb buffer
> - and then mark the second half / two thirds / of the thin air> slots as used, and make that region available
>through a special CMA
On Wed, 17 May 2023 08:35:10 +0200
Petr Tesařík wrote:
>[...]
> Anyway, my greatest objection to allocating additional swiotlb chunks is
> that _all_ of them must be searched to determine that the physical
> address does _not_ belong to a swiotlb, incurring performance penalty
I thought about th
On Wed, 17 May 2023 10:41:19 +0100
Catalin Marinas wrote:
> On Wed, May 17, 2023 at 08:56:53AM +0200, Christoph Hellwig wrote:
> > Just thinking out loud:
> >
> > - what if we always way overallocate the swiotlb buffer
> > - and then mark the second half / two thirds / >of the thin air> s
Hi Christoph,
On Wed, 17 May 2023 08:56:53 +0200
Christoph Hellwig wrote:
> Just thinking out loud:
>
> - what if we always way overallocate the swiotlb buffer
> - and then mark the second half / two thirds / of the thin air> slots as used, and make that region available
>through a sp
On Tue, May 16, 2023 at 08:39:42AM +0200, Petr Tesařík wrote:
> On Tue, 16 May 2023 08:13:09 +0200
> Christoph Hellwig wrote:
> > On Mon, May 15, 2023 at 07:43:52PM +, Michael Kelley (LINUX) wrote:
> > > FWIW, I don't think the approach you have implemented here will be
> > > practical to use
Hi Catalin,
On Tue, 16 May 2023 18:59:30 +0100
Catalin Marinas wrote:
> On Tue, May 16, 2023 at 08:39:42AM +0200, Petr Tesařík wrote:
> > On Tue, 16 May 2023 08:13:09 +0200
> > Christoph Hellwig wrote:
> > > On Mon, May 15, 2023 at 07:43:52PM +, Michael Kelley (LINUX) wrote:
> > > > FWI
Hi Christoph,
On Tue, 16 May 2023 08:13:09 +0200
Christoph Hellwig wrote:
> On Mon, May 15, 2023 at 07:43:52PM +, Michael Kelley (LINUX) wrote:
> > FWIW, I don't think the approach you have implemented here will be
> > practical to use for CoCo VMs (SEV, TDX, whatever else). The problem
> >
Hi Michael,
On Mon, 15 May 2023 19:43:52 +
"Michael Kelley (LINUX)" wrote:
> From: Petr Tesarik Sent: Tuesday, May 9, 2023
> 2:18 AM
> >
> > The software IO TLB was designed with the assumption that it is not
> > used much, especially on 64-bit systems, so a small fixed memory
> > area (c
From: Petr Tesarik Sent: Tuesday, May 9, 2023
2:18 AM
>
> The software IO TLB was designed with the assumption that it is not
> used much, especially on 64-bit systems, so a small fixed memory
> area (currently 64 MiB) is sufficient to handle the few cases which
> still require a bounce buffer.
12 matches
Mail list logo