From: Jason Gunthorpe <jgg@ziepe.ca>
To: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
"Aneesh Kumar K.V" <aneesh.kumar@kernel.org>,
linux-kernel@vger.kernel.org, iommu@lists.linux.dev,
linux-coco@lists.linux.dev, will@kernel.org, maz@kernel.org,
tglx@linutronix.de, robin.murphy@arm.com,
akpm@linux-foundation.org, steven.price@arm.com
Subject: Re: [RFC PATCH] arm64: swiotlb: dma: its: Ensure shared buffers are properly aligned
Date: Mon, 8 Sep 2025 11:58:45 -0300 [thread overview]
Message-ID: <20250908145845.GA699673@ziepe.ca> (raw)
In-Reply-To: <b5ee1ab3-f91f-4982-95c7-516f4968a6c9@arm.com>
On Mon, Sep 08, 2025 at 02:47:21PM +0100, Suzuki K Poulose wrote:
> On 08/09/2025 12:40, Catalin Marinas wrote:
> > On Mon, Sep 08, 2025 at 03:07:00PM +0530, Aneesh Kumar K.V wrote:
> > > Catalin Marinas <catalin.marinas@arm.com> writes:
> > > > On Fri, Sep 05, 2025 at 11:24:41AM +0530, Aneesh Kumar K.V (Arm) 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.
> > > >
> > > > So this is the case where the guest page size is smaller than the host
> > > > one. Just trying to understand what would go wrong if we don't do
> > > > anything here. Let's say the guest uses 4K pages and the host a 64K
> > > > pages. Within a 64K range, only a 4K is shared/decrypted. If the host
> > > > does not explicitly access the other 60K around the shared 4K, can
> > > > anything still go wrong? Is the hardware ok with speculative loads from
> > > > non-shared ranges?
> > >
> > > With features like guest_memfd, the goal is to explicitly prevent the
> > > host from mapping private memory, rather than relying on the host to
> > > avoid accessing those regions.
> >
> > Yes, if all the memory is private. At some point the guest will start
> > sharing memory with the host. In theory, the host could map more than it
> > was given access to as long as it doesn't touch the area around the
> > shared range. Not ideal and it may not match the current guest_memfd API
>
> The kernel may be taught not to touch the area, but it is tricky when
> the shared page gets mapped into the usespace and what it does with it.
But what happes?
The entire reason we have this nasty hyper-restrictive memfd private
memory is beacuse Intel takes a machine check if anything does it
wrong, and that is fatal and can't be handled.
Is ARM like that? I thought ARM had good faults on GPT violation that
could be handled in the same way as a normal page fault?
If ARM has proper faulting then you don't have an issue mapping 64K
into a userspace and just segfaulting the VMM if it does something
wrong.
If not, then sure you need all this unmapping stuff like Intel does :\
> True. The GPC Page Size is going to be 4K. At present the RMM S2 page
> size is fixed to 4K.
A 4k S2 is a pointless thing to do if the VMM is only going to approve
64k shared/private transitions :(
Jason
next prev parent reply other threads:[~2025-09-08 14:58 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
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 [this message]
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=20250908145845.GA699673@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=iommu@lists.linux.dev \
--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 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.