search for: config_device_private

...c: In function '__request_free_mem_region': kernel/resource.c:1653:28: error: 'PA_SECTION_SHIFT' undeclared (first use in this function); did you mean 'SECTIONS_PGSHIFT'? size = ALIGN(size, 1UL << PA_SECTION_SHIFT); because in current mainline, allmodconfig produces CONFIG_DEVICE_PRIVATE=n but in current linux-next, allmodconfig produces CONFIG_DEVICE_PRIVATE=y. But CONFIG_SPARSEMEM=n so the build breaks. Bisection fingers this commit, but reverting it doesn't seem to fix things. Could you take a look please? I'm seeing this from menuconfig: WARNING: unmet direct depen...

CONFIG_DEVICE_PRIVATE cannot be selected in configurations without ZONE_DEVICE: WARNING: unmet direct dependencies detected for DEVICE_PRIVATE Depends on [n]: ZONE_DEVICE [=n] Selected by [y]: - DRM_NOUVEAU_SVM [=y] && HAS_IOMEM [=y] && DRM_NOUVEAU [=y] && MMU [=y] && STAGING [=y]...

On Fri, May 8, 2020 at 5:00 PM Jason Gunthorpe <jgg at mellanox.com> wrote: > > On Fri, May 08, 2020 at 04:40:09PM +0200, Arnd Bergmann wrote: > > CONFIG_DEVICE_PRIVATE cannot be selected in configurations > > without ZONE_DEVICE: > > It is kind of unfortunate to lift dependencies from DEVICE_PRIVATE > into the users, is this really how kconfig is supposed to work or is > something else wrong here? Usually the problem is trying to use 'selec...

...return (r1->start <= r2->end && r1->end >= r2->start); > } > > +struct resource *devm_request_free_mem_region(struct device *dev, > + struct resource *base, unsigned long size); This appears to need a 'static inline' helper stub in the CONFIG_DEVICE_PRIVATE=n case, otherwise this compile error triggers: ld: mm/hmm.o: in function `hmm_devmem_add': /home/dwillia2/git/linux/mm/hmm.c:1427: undefined reference to `devm_request_free_mem_region'

From: Jason Gunthorpe <jgg at mellanox.com> There is no reason for a user to select this or not directly - it should be selected by drivers that are going to use the feature, similar to how CONFIG_HMM_MIRROR works. Currently all drivers provide a feature kconfig that will disable use of DEVICE_PRIVATE in that driver, allowing users to avoid enabling this if they don't want the

From: Jason Gunthorpe <jgg at mellanox.com> There is no reason for a user to select this or not directly - it should be selected by drivers that are going to use the feature, similar to how CONFIG_HMM_MIRROR works. Currently all drivers provide a feature kconfig that will disable use of DEVICE_PRIVATE in that driver, allowing users to avoid enabling this if they don't want the

...nux/hmm.h index 5c46b0f603fd..44a5ac738bb5 100644 --- a/include/linux/hmm.h +++ b/include/linux/hmm.h @@ -584,7 +584,7 @@ static inline void hmm_mm_destroy(struct mm_struct *mm) {} static inline void hmm_mm_init(struct mm_struct *mm) {} #endif /* IS_ENABLED(CONFIG_HMM_MIRROR) */ -#if IS_ENABLED(CONFIG_DEVICE_PRIVATE) || IS_ENABLED(CONFIG_DEVICE_PUBLIC) +#if IS_ENABLED(CONFIG_DEVICE_PRIVATE) struct hmm_devmem; struct page *hmm_vma_alloc_locked_page(struct vm_area_struct *vma, @@ -748,7 +748,7 @@ static inline unsigned long hmm_devmem_page_get_drvdata(const struct page *page) { return page->hmm_data;...

...ouble check me. Sure. > >> I would suggest you to check all the use of is_swap_pmd() and make sure the code >> can handle is_device_private_entry(). > > OK. > >> For new device private code, you might need to guard it either statically or dynamically in case >> CONFIG_DEVICE_PRIVATE is disabled. Potentially, you would like to make sure a system without >> CONFIG_DEVICE_PRIVATE will not see is_device_private_entry() == true and give errors when it does. > > I have compiled and run with CONFIG_DEVICE_PRIVATE off but I can test more combinations of > config setting...

...ures support THP but not THP migration (like ARM64), your code should still work. I would suggest you to check all the use of is_swap_pmd() and make sure the code can handle is_device_private_entry(). For new device private code, you might need to guard it either statically or dynamically in case CONFIG_DEVICE_PRIVATE is disabled. Potentially, you would like to make sure a system without CONFIG_DEVICE_PRIVATE will not see is_device_private_entry() == true and give errors when it does. > >> Do we need to support split_huge_pmd() if a page is migrated to device? Any new code >> needed in split_hug...

So I did a 'make allmodconfig' and then a 'make' on an RPi4 ARM box, and it decided that CONFIG_SPARSEMEM=n was OK (so an include of linux/mmzone.h doesn't define some needed values). The offending code in resource.c is wrapped in a #ifdef CONFIG_DEVICE_PRIVATE, which throws a whinge during 'make menuconfig' or 'make allmodconfig': WARNING: unmet direct dependencies detected for DEVICE_PRIVATE Depends on [n]: ZONE_DEVICE [=n] Selected by [m]: - DRM_NOUVEAU_SVM [=y] && HAS_IOMEM [=y] && DRM_NOUVEAU [=m] && MMU...

CONFIG_MIGRATE_VMA_HELPER guards helpers that are required for proper devic private memory support. Remove the option and just check for CONFIG_DEVICE_PRIVATE instead. Signed-off-by: Christoph Hellwig <hch at lst.de> --- drivers/gpu/drm/nouveau/Kconfig | 1 - mm/Kconfig | 3 --- mm/migrate.c | 4 ++-- 3 files changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/nouveau/Kconfig b/drivers/gp...

...struct page *device_private_entry_to_page(swp_entry_t entry) { return pfn_to_page(swp_offset(entry)); } - -vm_fault_t device_private_entry_fault(struct vm_area_struct *vma, - unsigned long addr, - swp_entry_t entry, - unsigned int flags, - pmd_t *pmdp); #else /* CONFIG_DEVICE_PRIVATE */ static inline swp_entry_t make_device_private_entry(struct page *page, bool write) { @@ -164,15 +158,6 @@ static inline struct page *device_private_entry_to_page(swp_entry_t entry) { return NULL; } - -static inline vm_fault_t device_private_entry_fault(struct vm_area_struct *vma, -...

...S_HMM [=y] && DRM_NOUVEAU [=y] && STAGING [=y] mm/memory.o: In function `do_swap_page': memory.c:(.text+0x2754): undefined reference to `device_private_entry_fault' commit 5da25090ab04 ("mm/hmm: kconfig split HMM address space mirroring from device memory") split CONFIG_DEVICE_PRIVATE dependencies from ARCH_HAS_HMM to ARCH_HAS_HMM_DEVICE and ZONE_DEVICE, so enable DRM_NOUVEAU_SVM will trigger this warning, cause building failed. Reported-by: Hulk Robot <hulkci at huawei.com> Fixes: 5da25090ab04 ("mm/hmm: kconfig split HMM address space mirroring from device memory&qu...

...struct page *device_private_entry_to_page(swp_entry_t entry) { return pfn_to_page(swp_offset(entry)); } - -vm_fault_t device_private_entry_fault(struct vm_area_struct *vma, - unsigned long addr, - swp_entry_t entry, - unsigned int flags, - pmd_t *pmdp); #else /* CONFIG_DEVICE_PRIVATE */ static inline swp_entry_t make_device_private_entry(struct page *page, bool write) { @@ -164,15 +158,6 @@ static inline struct page *device_private_entry_to_page(swp_entry_t entry) { return NULL; } - -static inline vm_fault_t device_private_entry_fault(struct vm_area_struct *vma, -...

...entry) > { > return pfn_to_page(swp_offset(entry)); > } > - > -vm_fault_t device_private_entry_fault(struct vm_area_struct *vma, > - unsigned long addr, > - swp_entry_t entry, > - unsigned int flags, > - pmd_t *pmdp); > #else /* CONFIG_DEVICE_PRIVATE */ > static inline swp_entry_t make_device_private_entry(struct page *page, bool write) > { > @@ -164,15 +158,6 @@ static inline struct page *device_private_entry_to_page(swp_entry_t entry) > { > return NULL; > } > - > -static inline vm_fault_t device_private_entr...

...I'll fix this up for v2 and you can double check me. > I would suggest you to check all the use of is_swap_pmd() and make sure the code > can handle is_device_private_entry(). OK. > For new device private code, you might need to guard it either statically or dynamically in case > CONFIG_DEVICE_PRIVATE is disabled. Potentially, you would like to make sure a system without > CONFIG_DEVICE_PRIVATE will not see is_device_private_entry() == true and give errors when it does. I have compiled and run with CONFIG_DEVICE_PRIVATE off but I can test more combinations of config settings. >> >&...

...gt;> I would suggest you to check all the use of is_swap_pmd() and make sure the code > >> can handle is_device_private_entry(). > > > > OK. > > > >> For new device private code, you might need to guard it either statically or dynamically in case > >> CONFIG_DEVICE_PRIVATE is disabled. Potentially, you would like to make sure a system without > >> CONFIG_DEVICE_PRIVATE will not see is_device_private_entry() == true and give errors when it does. > > > > I have compiled and run with CONFIG_DEVICE_PRIVATE off but I can test more combinations of >...

On Mon, Jun 17, 2019 at 10:37:12AM -0700, Dan Williams wrote: > > +struct resource *devm_request_free_mem_region(struct device *dev, > > + struct resource *base, unsigned long size); > > This appears to need a 'static inline' helper stub in the > CONFIG_DEVICE_PRIVATE=n case, otherwise this compile error triggers: > > ld: mm/hmm.o: in function `hmm_devmem_add': > /home/dwillia2/git/linux/mm/hmm.c:1427: undefined reference to > `devm_request_free_mem_region' *sigh* - hmm_devmem_add already only works for device private memory, so it shouldn&...

...| 14 -------------- 2 files changed, 17 deletions(-) diff --git a/include/linux/hmm.h b/include/linux/hmm.h index ba19c19e24ed..1d55b7ea2da6 100644 --- a/include/linux/hmm.h +++ b/include/linux/hmm.h @@ -587,9 +587,6 @@ static inline void hmm_mm_init(struct mm_struct *mm) {} #if IS_ENABLED(CONFIG_DEVICE_PRIVATE) struct hmm_devmem; -struct page *hmm_vma_alloc_locked_page(struct vm_area_struct *vma, - unsigned long addr); - /* * struct hmm_devmem_ops - callback for ZONE_DEVICE memory events * diff --git a/mm/hmm.c b/mm/hmm.c index e4470462298f..fdbd48771292 100644 --- a/mm/hmm.c +++ b/mm/h...

On Fri, May 08, 2020 at 05:05:03PM +0200, Arnd Bergmann wrote: > On Fri, May 8, 2020 at 5:00 PM Jason Gunthorpe <jgg at mellanox.com> wrote: > > > > On Fri, May 08, 2020 at 04:40:09PM +0200, Arnd Bergmann wrote: > > > CONFIG_DEVICE_PRIVATE cannot be selected in configurations > > > without ZONE_DEVICE: > > > > It is kind of unfortunate to lift dependencies from DEVICE_PRIVATE > > into the users, is this really how kconfig is supposed to work or is > > something else wrong here? > > Usually the...