Re: [RFC PATCH 7/7] mm: zswap: Use acomp virtual address interface

[Yosry Ahmed <yosry.ahmed@linux.dev>]

On Wed, Mar 05, 2025 at 10:10:46PM +0800, Herbert Xu wrote:
> On Wed, Mar 05, 2025 at 03:46:18PM +0800, Herbert Xu wrote:
> >
> > > Also, please take a look at patch 2 in this series for another reason, I
> > > want to make sure if your virtual address series can be used to remove
> > > the !virt_addr_valid() memcpy() case completely.
> > 
> > Yes it should work provided that you specify the memory as nondma.
> 
> Actually you can do better than that, specify the memory as nondma
> if IS_ENABLED(CONFIG_HIGHMEM), and otherwise as virt.
> 
> The idea is that we only have two hardware offload drivers, both
> from Intel and they're probably not going to be used on platforms
> with HIGHMEM.
> 
> So something like:
> 
> 	if (IS_ENABLED(CONFIG_HIGHMEM))
> 		acomp_request_set_nondma(acomp_ctx->req, src, dst, entry->length, PAGE_SIZE);
> 	else
> 		acomp_request_set_virt(acomp_ctx->req, src, dst, entry->length, PAGE_SIZE);

Well, ideally it would be based on whether the address itself is a
highmem address or not, it may not be, even if CONFIG_HIGHMEM is
enabled.

> 
> Of course all this would disappear if we used SG lists properly.

Zswap is already using an SG list when calling into the crypto API. The
problem is that SGs (i.e. sg_init_one()) does not support kmap highmem
addresses. Is there a fundamental reason this can't happen, or is it
just sg_set_bug() using virt_to_page().

Also, since the crypto API is using SG lists internally as far as I can
tell, how does acomp_request_set_nondma() essentially deal with this? I
don't understand why we need to use a separate nondma API for highmem.