search for: max_physmem_bit

..., all > the Xen configs we use have SPARSEMEM_VMEMMAP enabled. Interesting... we have config ARCH_SPARSEMEM_ENABLE depend on !XEN at SUSE. Figured this was a generic issue. The SUSE kernels are based on 3.12 though, but anyway with it enabled I do get compile failures because of redefinition of MAX_PHYSMEM_BITS which we provide on Xen set to 43 for some reason (can't find that justification), so it doesn't use the default 46 that would be used otherwise. But another reason seems to be the lack of forward porting yet PAT support for PV domains -- commit 47591df50 upstream which requires us to stil...

..., all > the Xen configs we use have SPARSEMEM_VMEMMAP enabled. Interesting... we have config ARCH_SPARSEMEM_ENABLE depend on !XEN at SUSE. Figured this was a generic issue. The SUSE kernels are based on 3.12 though, but anyway with it enabled I do get compile failures because of redefinition of MAX_PHYSMEM_BITS which we provide on Xen set to 43 for some reason (can't find that justification), so it doesn't use the default 46 that would be used otherwise. But another reason seems to be the lack of forward porting yet PAT support for PV domains -- commit 47591df50 upstream which requires us to stil...

.../include/asm/bug.h:60, from ./include/linux/bug.h:5, from ./include/linux/mmdebug.h:5, from ./include/linux/gfp.h:5, from ./include/linux/slab.h:15, from kernel/resource.c:17: kernel/resource.c:1654:48: error: 'MAX_PHYSMEM_BITS' undeclared (first use in this function); did you mean 'MAX_UINSN_BYTES'? end = min_t(unsigned long, base->end, (1UL << MAX_PHYSMEM_BITS) - 1); ^~~~~~~~~~~~~~~~ ./include/linux/kernel.h:848:40: note: in definition of macro '...

...y] && MMU [=y] && STAGING [=y] kernel/resource.c:1653:28: error: use of undeclared identifier 'PA_SECTION_SHIFT' size = ALIGN(size, 1UL << PA_SECTION_SHIFT); ^ kernel/resource.c:1654:48: error: use of undeclared identifier 'MAX_PHYSMEM_BITS' Add a dependency for Nouveau to avoid broken randconfig builds. Fixes: d2c63df2242e ("mm/hmm: make CONFIG_DEVICE_PRIVATE into a select") Signed-off-by: Arnd Bergmann <arnd at arndb.de> --- drivers/gpu/drm/nouveau/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/d...

...struct pages. + */ +struct resource *devm_request_free_mem_region(struct device *dev, + struct resource *base, unsigned long size) +{ + resource_size_t end, addr; + struct resource *res; + + size = ALIGN(size, 1UL << PA_SECTION_SHIFT); + end = min_t(unsigned long, base->end, (1UL << MAX_PHYSMEM_BITS) - 1); + addr = end - size + 1UL; + + for (; addr > size && addr >= base->start; addr -= size) { + if (region_intersects(addr, size, 0, IORES_DESC_NONE) != + REGION_DISJOINT) + continue; + + res = devm_request_mem_region(dev, addr, size, dev_name(dev)); + if (!res) + ret...

...gs we use have SPARSEMEM_VMEMMAP enabled. > > Interesting... we have config ARCH_SPARSEMEM_ENABLE depend on !XEN at > SUSE. Figured this was a generic issue. The SUSE kernels are based on > 3.12 though, but anyway with it enabled I do get compile failures > because of redefinition of MAX_PHYSMEM_BITS which we provide on Xen > set to 43 for some reason (can't find that justification), so it > doesn't use the default 46 that would be used otherwise. But another > reason seems to be the lack of forward porting yet PAT support for PV > domains -- commit 47591df50 upstream which...

Andrey, I believe that on Xen we should disable kasan, would like confirmation from someone on xen-devel though. Here's the thing though -- if true -- I'd like to do it *properly*, where *properly* means addressing a bit of architecture. A simple Kconfig slap seems rather reactive. I'd like to address a way to properly ensure we don't run into this and other similar issues in the

Andrey, I believe that on Xen we should disable kasan, would like confirmation from someone on xen-devel though. Here's the thing though -- if true -- I'd like to do it *properly*, where *properly* means addressing a bit of architecture. A simple Kconfig slap seems rather reactive. I'd like to address a way to properly ensure we don't run into this and other similar issues in the

...struct pages. + */ +struct resource *devm_request_free_mem_region(struct device *dev, + struct resource *base, unsigned long size) +{ + resource_size_t end, addr; + struct resource *res; + + size = ALIGN(size, 1UL << PA_SECTION_SHIFT); + end = min_t(unsigned long, base->end, (1UL << MAX_PHYSMEM_BITS) - 1); + addr = end - size + 1UL; + + for (; addr > size && addr >= base->start; addr -= size) { + if (region_intersects(addr, size, 0, IORES_DESC_NONE) != + REGION_DISJOINT) + continue; + + res = devm_request_mem_region(dev, addr, size, dev_name(dev)); + if (!res) + ret...

...*devm_request_free_mem_region(struct device *dev, > + struct resource *base, unsigned long size) > +{ > + resource_size_t end, addr; > + struct resource *res; > + > + size = ALIGN(size, 1UL << PA_SECTION_SHIFT); > + end = min_t(unsigned long, base->end, (1UL << MAX_PHYSMEM_BITS) - 1); > + addr = end - size + 1UL; > + > + for (; addr > size && addr >= base->start; addr -= size) { > + if (region_intersects(addr, size, 0, IORES_DESC_NONE) != > + REGION_DISJOINT) > + continue; > + > + res = devm_request_mem_region(dev, addr, si...

...EMEM_VMEMMAP enabled. >> >> Interesting... we have config ARCH_SPARSEMEM_ENABLE depend on !XEN at >> SUSE. Figured this was a generic issue. The SUSE kernels are based on >> 3.12 though, but anyway with it enabled I do get compile failures >> because of redefinition of MAX_PHYSMEM_BITS which we provide on Xen >> set to 43 for some reason (can't find that justification), so it >> doesn't use the default 46 that would be used otherwise. But another >> reason seems to be the lack of forward porting yet PAT support for PV >> domains -- commit 47591df5...

...*devm_request_free_mem_region(struct device *dev, > + struct resource *base, unsigned long size) > +{ > + resource_size_t end, addr; > + struct resource *res; > + > + size = ALIGN(size, 1UL << PA_SECTION_SHIFT); > + end = min_t(unsigned long, base->end, (1UL << MAX_PHYSMEM_BITS) - 1); Even fixed it to use min_t > + addr = end - size + 1UL; > + for (; addr > size && addr >= base->start; addr -= size) { > + if (region_intersects(addr, size, 0, IORES_DESC_NONE) != > + REGION_DISJOINT) > + continue; The FIXME about the algorithm cost...

If subblock size is large (e.g. 1G) 32 bit math involving it can overflow. Rather than try to catch all instances of that, let's tweak block size to 64 bit. It ripples through UAPI which is an ABI change, but it's not too late to make it, and it will allow supporting >4Gbyte blocks while might become necessary down the road. Fixes: 5f1f79bbc9e26 ("virtio-mem: Paravirtualized

If subblock size is large (e.g. 1G) 32 bit math involving it can overflow. Rather than try to catch all instances of that, let's tweak block size to 64 bit. It ripples through UAPI which is an ABI change, but it's not too late to make it, and it will allow supporting >4Gbyte blocks while might become necessary down the road. Fixes: 5f1f79bbc9e26 ("virtio-mem: Paravirtualized

...b_id); + if (rc) + return rc; + virtio_mem_mb_set_state(vm, mb_id, VIRTIO_MEM_MB_STATE_UNUSED); + } + + return 0; +} + +/* + * Update all parts of the config that could have changed. + */ +static void virtio_mem_refresh_config(struct virtio_mem *vm) +{ + const uint64_t phys_limit = 1UL << MAX_PHYSMEM_BITS; + uint64_t new_plugged_size, usable_region_size, end_addr; + + /* the plugged_size is just a reflection of what _we_ did previously */ + virtio_cread(vm->vdev, struct virtio_mem_config, plugged_size, + &new_plugged_size); + if (WARN_ON_ONCE(new_plugged_size != vm->plugged_size)) +...

Hi Dan, Jérôme and Jason, below is a series that cleans up the dev_pagemap interface so that it is more easily usable, which removes the need to wrap it in hmm and thus allowing to kill a lot of code Diffstat: 22 files changed, 245 insertions(+), 802 deletions(-) Git tree: git://git.infradead.org/users/hch/misc.git hmm-devmem-cleanup Gitweb:

This series is based on v5.7-rc4. The patches are located at: https://github.com/davidhildenbrand/linux.git virtio-mem-v4 This is basically a resend of v3 [1], now based on v5.7-rc4 and restested. One patch was reshuffled and two ACKs I missed to add were added. The rebase did not require any modifications to patches. Details about virtio-mem can be found in the cover letter of v2 [2]. A

This series is based on latest linux-next. The patches are located at: https://github.com/davidhildenbrand/linux.git virtio-mem-v3 Patch #1 - #10 where contained in v2 and only contain minor modifications (mostly smaller fixes). The remaining patches are new and contain smaller optimizations. Details about virtio-mem can be found in the cover letter of v2 [1]. A basic QEMU implementation was

This series is based on latest linux-next. The patches are located at: https://github.com/davidhildenbrand/linux.git virtio-mem-v3 Patch #1 - #10 where contained in v2 and only contain minor modifications (mostly smaller fixes). The remaining patches are new and contain smaller optimizations. Details about virtio-mem can be found in the cover letter of v2 [1]. A basic QEMU implementation was

This series is based on latest linux-next. The patches are located at: https://github.com/davidhildenbrand/linux.git virtio-mem-v2 I now have acks for all !virtio-mem changes. I'll be happy to get review feedback, testing reports, etc. for the virtio-mem changes. If there are no further comments, I guess this is good to go as a v1 soon. The basic idea of virtio-mem is to provide a