linux-coco.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Aneesh Kumar K.V <aneesh.kumar@kernel.org>
To: Thomas Gleixner <tglx@linutronix.de>,
	linux-kernel@vger.kernel.org, iommu@lists.linux.dev,
	linux-coco@lists.linux.dev
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	will@kernel.org, maz@kernel.org, robin.murphy@arm.com,
	suzuki.poulose@arm.com, akpm@linux-foundation.org, jgg@ziepe.ca,
	steven.price@arm.com
Subject: Re: [RFC PATCH] arm64: swiotlb: dma: its: Ensure shared buffers are properly aligned
Date: Mon, 08 Sep 2025 14:14:31 +0530	[thread overview]
Message-ID: <yq5aldmp1ggg.fsf@kernel.org> (raw)
In-Reply-To: <87qzwlwciv.ffs@tglx>

Thomas Gleixner <tglx@linutronix.de> writes:

> On Fri, Sep 05 2025 at 11:24, Aneesh Kumar K. V. wrote:
>> When running with private memory guests, the guest kernel must allocate
>> memory with specific constraints when sharing it with the hypervisor.
>>
>> These shared memory buffers are also accessed by the host kernel, which
>> means they must be aligned to the host kernel's page size.
>>
>> This patch introduces a new helper, arch_shared_mem_alignment(), which
>
> # git grep "This patch" Documentation/process/
>
>> can be used to enforce proper alignment of shared buffers.
>>
>> The actual implementation of arch_shared_mem_alignment() is deferred
>> to a follow-up patch.
>>
>> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
>> ---
>>  arch/arm64/include/asm/mem_encrypt.h |  6 ++++++
>>  arch/arm64/mm/init.c                 |  4 +++-
>>  arch/arm64/mm/mem_encrypt.c          |  6 ++++++
>>  drivers/irqchip/irq-gic-v3-its.c     |  8 ++++++--
>>  include/linux/mem_encrypt.h          |  7 +++++++
>>  include/linux/swiotlb.h              |  7 ++++---
>>  kernel/dma/direct.c                  |  7 +++++++
>>  kernel/dma/pool.c                    |  1 +
>>  kernel/dma/swiotlb.c                 | 28 +++++++++++++++++-----------
>
> This does too many things at once and breaks all swiotlb users except
> arm64. Seriously?
>
>> -void swiotlb_init(bool addressing_limited, unsigned int flags);
>> +void swiotlb_init(bool addressing_limited, unsigned int alignment, unsigned int flags);
>
> Why do you need this alignment argument in the first place?
>
> In quite some other places you use arch_shared_mem_alignment(), which
> defaults to PAGE_SIZE if the architecture does not implement it's own
> variant. What's preventing you from using that in the init functions as
> well?
>

This patch is required to ensure that a guest using a 4K page size can
safely share pages with a non-secure host that uses a 64K page size.
Without this, the non-secure host may inadvertently map protected
memory.

Memory attribute tracking in the non-secure host (via
set_guest_memory_attributes()) operates in units of the host's
PAGE_SIZE. Attempting to set memory attributes at 4K granularity—when
the host uses 64K pages—will fail with -EINVAL. This makes it impossible
to correctly manage mixed-private/shared regions without enforcing
alignment between guest and host page sizes or introducing finer-grained
handling.


-aneesh

  reply	other threads:[~2025-09-08  8:44 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-05  5:54 [RFC PATCH] arm64: swiotlb: dma: its: Ensure shared buffers are properly aligned Aneesh Kumar K.V (Arm)
2025-09-05  8:04 ` Thomas Gleixner
2025-09-08  8:44   ` Aneesh Kumar K.V [this message]
2025-09-05 13:13 ` Catalin Marinas
2025-09-05 16:22   ` Jason Gunthorpe
2025-09-05 20:25     ` Catalin Marinas
2025-09-08  9:12     ` Suzuki K Poulose
2025-09-08  9:37   ` Aneesh Kumar K.V
2025-09-08 11:40     ` Catalin Marinas
2025-09-08 13:47       ` Suzuki K Poulose
2025-09-08 14:58         ` Jason Gunthorpe
2025-09-08 15:39           ` Steven Price
2025-09-08 17:25             ` Catalin Marinas
2025-09-10 10:08               ` Steven Price
2025-09-12 14:59                 ` Catalin Marinas
2025-09-08 17:55             ` Jason Gunthorpe

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=yq5aldmp1ggg.fsf@kernel.org \
    --to=aneesh.kumar@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=catalin.marinas@arm.com \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@ziepe.ca \
    --cc=linux-coco@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=steven.price@arm.com \
    --cc=suzuki.poulose@arm.com \
    --cc=tglx@linutronix.de \
    --cc=will@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).