Re: __HAVE_ARCH_PTE_DEVMAP - bug or intended behaviour?

[Dan Williams <dan.j.williams@intel.com>]

On Thu, Nov 1, 2018 at 1:10 PM Robin Murphy <robin.murphy@arm.com> wrote:
>
> On 31/10/2018 20:41, Dan Williams wrote:
> > On Wed, Oct 31, 2018 at 10:08 AM Robin Murphy <robin.murphy@arm.com> wrote:
> >>
> >> Hi mm folks,
> >>
> >> I'm looking at ZONE_DEVICE support for arm64, and trying to make sense
> >> of a build failure has led me down the rabbit hole of pfn_t.h, and
> >> specifically __HAVE_ARCH_PTE_DEVMAP in this first instance.
> >>
> >> The failure itself is a link error in remove_migration_pte() due to a
> >> missing definition of pte_mkdevmap(), but I'm a little confused at the
> >> fact that it's explicitly declared without a definition, as if that
> >> breakage is deliberate.
> >
> > It's deliberate, it's only there to allow mm/memory.c to compile. The
> > compiler can see that pfn_t_devmap(pfn) is always false in the
> > !__HAVE_ARCH_PTE_DEVMAP case and throws away the attempt to link to
> > pte_devmap().
> >
> > The summary is that an architecture needs to devote a free/software
> > pte bit for Linux to indicate "device pfns".
>
> Thanks for the explanation(s), that's been super helpful. So
> essentially, the WIP configuration I currently have
> (ARCH_HAS_ZONE_DEVICE=y but !__HAVE_ARCH_PTE_DEVMAP) is fundamentally
> incomplete, and even if I convince a ZONE_DEVICE=y config to build with
> the devmap stubs, it would end up going wrong in exciting ways at
> runtime - is that the gist of it?

Yes, exactly.

> If that is the case, then I might also
> have a go at streamlining some of the configs to make those dependencies
> more apparent.

Sounds good.