On Thu, Nov 1, 2018 at 1:10 PM Robin Murphy <robin.murphy@xxxxxxx> wrote: > > On 31/10/2018 20:41, Dan Williams wrote: > > On Wed, Oct 31, 2018 at 10:08 AM Robin Murphy <robin.murphy@xxxxxxx> 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.
