From: Steve Capper <Steve.Capper@arm.com>
To: Suzuki Poulose <Suzuki.Poulose@arm.com>
Cc: "ard.biesheuvel@linaro.org" <ard.biesheuvel@linaro.org>,
"jcm@redhat.com" <jcm@redhat.com>,
Will Deacon <Will.Deacon@arm.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
Catalin Marinas <Catalin.Marinas@arm.com>, nd <nd@arm.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH V4 5/6] arm64: mm: introduce 52-bit userspace support
Date: Thu, 6 Dec 2018 14:52:46 +0000 [thread overview]
Message-ID: <20181206145236.GA408@capper-debian.cambridge.arm.com> (raw)
In-Reply-To: <c87c833a-7dfc-6cd4-aad7-119df9bd7178@arm.com>
On Thu, Dec 06, 2018 at 02:35:20PM +0000, Suzuki K Poulose wrote:
>
>
> On 06/12/2018 12:26, Steve Capper wrote:
> > On Wed, Dec 05, 2018 at 06:22:27PM +0000, Suzuki K Poulose wrote:
> > > Hi Steve,
> > >
> > [...]
> > > I think we may need a check for the secondary CPUs to make sure that they have
> > > the 52bit support once the boot CPU has decided to use the feature and fail the
> > > CPU bring up (just like we do for the granule support).
> > >
> > > Suzuki
> >
> > Hi Suzuki,
> > I have just written a patch to detect a mismatch between 52-bit VA that
> > is being tested now.
> >
> > As 52-bit kernel VA support is coming in future, the patch checks for a
> > mismatch during the secondary boot path and, if one is found, prevents
> > the secondary from booting (and displays an error message to the user).
>
> Right now, it is the boot CPU which decides the Userspace 52bit VA, isn't it ?
> Irrespective of the kernel VA support, the userspace must be able to run on
> all the CPUs on the system, right ? So don't we need it now, with this series ?
Hi Suzuki,
Yes the boot CPU determines vabits_user. My idea was to have the
secondary CPUs check to see if vabits_user was 52, and if so, then check
to see if it's capable of supporting 52-bit. If not, then it stops
booting (and sets a flag to indicate why).
This check will be valid for 52-bit userspace support and also valid for
52-bit kernel support (as the check is performed before the secondary
mmu is enabled). I didn't want to write a higher level detection
routine for the userspace support and then have to re-write it later
when introducing 52-bit kernel support.
I'm happy to do what works though, I thought this way was simplest :-).
Cheers,
--
Steve
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Steve Capper <Steve.Capper@arm.com>
To: Suzuki Poulose <Suzuki.Poulose@arm.com>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Catalin Marinas <Catalin.Marinas@arm.com>,
Will Deacon <Will.Deacon@arm.com>,
"jcm@redhat.com" <jcm@redhat.com>,
"ard.biesheuvel@linaro.org" <ard.biesheuvel@linaro.org>,
nd <nd@arm.com>
Subject: Re: [PATCH V4 5/6] arm64: mm: introduce 52-bit userspace support
Date: Thu, 6 Dec 2018 14:52:46 +0000 [thread overview]
Message-ID: <20181206145236.GA408@capper-debian.cambridge.arm.com> (raw)
In-Reply-To: <c87c833a-7dfc-6cd4-aad7-119df9bd7178@arm.com>
On Thu, Dec 06, 2018 at 02:35:20PM +0000, Suzuki K Poulose wrote:
>
>
> On 06/12/2018 12:26, Steve Capper wrote:
> > On Wed, Dec 05, 2018 at 06:22:27PM +0000, Suzuki K Poulose wrote:
> > > Hi Steve,
> > >
> > [...]
> > > I think we may need a check for the secondary CPUs to make sure that they have
> > > the 52bit support once the boot CPU has decided to use the feature and fail the
> > > CPU bring up (just like we do for the granule support).
> > >
> > > Suzuki
> >
> > Hi Suzuki,
> > I have just written a patch to detect a mismatch between 52-bit VA that
> > is being tested now.
> >
> > As 52-bit kernel VA support is coming in future, the patch checks for a
> > mismatch during the secondary boot path and, if one is found, prevents
> > the secondary from booting (and displays an error message to the user).
>
> Right now, it is the boot CPU which decides the Userspace 52bit VA, isn't it ?
> Irrespective of the kernel VA support, the userspace must be able to run on
> all the CPUs on the system, right ? So don't we need it now, with this series ?
Hi Suzuki,
Yes the boot CPU determines vabits_user. My idea was to have the
secondary CPUs check to see if vabits_user was 52, and if so, then check
to see if it's capable of supporting 52-bit. If not, then it stops
booting (and sets a flag to indicate why).
This check will be valid for 52-bit userspace support and also valid for
52-bit kernel support (as the check is performed before the secondary
mmu is enabled). I didn't want to write a higher level detection
routine for the userspace support and then have to re-write it later
when introducing 52-bit kernel support.
I'm happy to do what works though, I thought this way was simplest :-).
Cheers,
--
Steve
next prev parent reply other threads:[~2018-12-06 14:53 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-05 16:41 [PATCH V4 0/6] 52-bit userspace VAs Steve Capper
2018-12-05 16:41 ` Steve Capper
2018-12-05 16:41 ` [PATCH V4 1/6] mm: mmap: Allow for "high" userspace addresses Steve Capper
2018-12-05 16:41 ` Steve Capper
2018-12-05 16:41 ` [PATCH V4 2/6] arm64: mm: Introduce DEFAULT_MAP_WINDOW Steve Capper
2018-12-05 16:41 ` Steve Capper
2018-12-05 17:36 ` Catalin Marinas
2018-12-05 17:36 ` Catalin Marinas
2018-12-06 12:24 ` Steve Capper
2018-12-06 12:24 ` Steve Capper
2018-12-05 16:41 ` [PATCH V4 3/6] arm64: mm: Define arch_get_mmap_end, arch_get_mmap_base Steve Capper
2018-12-05 16:41 ` Steve Capper
2018-12-05 16:41 ` [PATCH V4 4/6] arm64: mm: Offset TTBR1 to allow 52-bit PTRS_PER_PGD Steve Capper
2018-12-05 16:41 ` Steve Capper
2018-12-06 11:50 ` Catalin Marinas
2018-12-06 11:50 ` Catalin Marinas
2018-12-06 12:27 ` Steve Capper
2018-12-06 12:27 ` Steve Capper
2018-12-05 16:41 ` [PATCH V4 5/6] arm64: mm: introduce 52-bit userspace support Steve Capper
2018-12-05 16:41 ` Steve Capper
2018-12-05 18:22 ` Suzuki K Poulose
2018-12-05 18:22 ` Suzuki K Poulose
2018-12-06 12:26 ` Steve Capper
2018-12-06 12:26 ` Steve Capper
2018-12-06 14:35 ` Suzuki K Poulose
2018-12-06 14:35 ` Suzuki K Poulose
2018-12-06 14:52 ` Steve Capper [this message]
2018-12-06 14:52 ` Steve Capper
2018-12-05 16:41 ` [PATCH V4 6/6] arm64: mm: Allow forcing all userspace addresses to 52-bit Steve Capper
2018-12-05 16:41 ` Steve Capper
2018-12-06 11:51 ` Catalin Marinas
2018-12-06 11:51 ` Catalin Marinas
2018-12-06 12:28 ` Steve Capper
2018-12-06 12:28 ` Steve Capper
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=20181206145236.GA408@capper-debian.cambridge.arm.com \
--to=steve.capper@arm.com \
--cc=Catalin.Marinas@arm.com \
--cc=Suzuki.Poulose@arm.com \
--cc=Will.Deacon@arm.com \
--cc=ard.biesheuvel@linaro.org \
--cc=jcm@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mm@kvack.org \
--cc=nd@arm.com \
/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.