search for: memory_notify

tree: https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git vhost head: f3861bc96a7e130943e1975e571ae62c0319b064 commit: 5f1f79bbc9e26fa9412fa9522f957bb8f030c442 [18/52] virtio-mem: Paravirtualized memory hotplug compiler: gcc-9 (Debian 9.3.0-13) 9.3.0 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot <lkp at intel.com> cppcheck

On Wed 16-10-19 16:14:52, David Hildenbrand wrote: > On 16.10.19 16:03, Michal Hocko wrote: [...] > > But why cannot you keep the reference count at 1 (do get_page when > > offlining the page)? In other words as long as the driver knows the page > > has been returned to the host then it has ref count at 1. Once the page > > is returned to the guest for whatever reason it

On Wed 16-10-19 16:14:52, David Hildenbrand wrote: > On 16.10.19 16:03, Michal Hocko wrote: [...] > > But why cannot you keep the reference count at 1 (do get_page when > > offlining the page)? In other words as long as the driver knows the page > > has been returned to the host then it has ref count at 1. Once the page > > is returned to the guest for whatever reason it

...the buddy is problematic for various reasons. Let's have a > look at __offline_pages(): > > 1) start_isolate_page_range() > -> offline pages with a reference count of one will be detected as unmovable > -> BAD, we abort right away. We could hack around that. > > 2) memory_notify(MEM_GOING_OFFLINE, &arg); > -> Here, we could release all pages to the buddy, clearing PG_offline > -> BAD, PF_offline must not be cleared so dumping tools will not touch > these pages. I don't see a way to hack around that. > > 3) scan_movable_pages() ... > &gt...

...the buddy is problematic for various reasons. Let's have a > look at __offline_pages(): > > 1) start_isolate_page_range() > -> offline pages with a reference count of one will be detected as unmovable > -> BAD, we abort right away. We could hack around that. > > 2) memory_notify(MEM_GOING_OFFLINE, &arg); > -> Here, we could release all pages to the buddy, clearing PG_offline > -> BAD, PF_offline must not be cleared so dumping tools will not touch > these pages. I don't see a way to hack around that. > > 3) scan_movable_pages() ... > &gt...

...memory remove. Returning them to the buddy is problematic for various reasons. Let's have a look at __offline_pages(): 1) start_isolate_page_range() -> offline pages with a reference count of one will be detected as unmovable -> BAD, we abort right away. We could hack around that. 2) memory_notify(MEM_GOING_OFFLINE, &arg); -> Here, we could release all pages to the buddy, clearing PG_offline -> BAD, PF_offline must not be cleared so dumping tools will not touch these pages. I don't see a way to hack around that. 3) scan_movable_pages() ... 4a) memory_notify(MEM_OFFLINE, &...

tree: https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git vhost head: da1742791d8c0c0a8e5471f181549c4726a5c5f9 commit: 7527631e900d464ed2d533f799cb0da2b29cc6f0 [8/22] virtio-mem: Paravirtualized memory hotplug config: x86_64-randconfig-b002-20200505 (attached as .config) compiler: gcc-7 (Ubuntu 7.5.0-6ubuntu2) 7.5.0 reproduce: git checkout

tree: https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git vhost head: da1742791d8c0c0a8e5471f181549c4726a5c5f9 commit: 7527631e900d464ed2d533f799cb0da2b29cc6f0 [8/22] virtio-mem: Paravirtualized memory hotplug config: x86_64-randconfig-b002-20200505 (attached as .config) compiler: gcc-7 (Ubuntu 7.5.0-6ubuntu2) 7.5.0 reproduce: git checkout

...for various reasons. Let's have a >> look at __offline_pages(): >> >> 1) start_isolate_page_range() >> -> offline pages with a reference count of one will be detected as unmovable >> -> BAD, we abort right away. We could hack around that. >> >> 2) memory_notify(MEM_GOING_OFFLINE, &arg); >> -> Here, we could release all pages to the buddy, clearing PG_offline >> -> BAD, PF_offline must not be cleared so dumping tools will not touch >> these pages. I don't see a way to hack around that. >> >> 3) scan_movable_p...

...start_isolate_page_range() > -> offline pages with a reference count of one will be detected as > unmovable -> offlining aborted. (see below on the memory isolation notifier) I am assuming that has_unmovable_pages would skip over those pages. Your patch already does that, no? > 2) memory_notify(MEM_GOING_OFFLINE, &arg); > -> Here, we could release all pages to the buddy, clearing PG_offline > -> PF_offline must not be cleared so dumping tools will not touch > these pages. There is a time where pages are !PageBuddy() and > !PageOffline(). Well, this is fully un...

...start_isolate_page_range() > -> offline pages with a reference count of one will be detected as > unmovable -> offlining aborted. (see below on the memory isolation notifier) I am assuming that has_unmovable_pages would skip over those pages. Your patch already does that, no? > 2) memory_notify(MEM_GOING_OFFLINE, &arg); > -> Here, we could release all pages to the buddy, clearing PG_offline > -> PF_offline must not be cleared so dumping tools will not touch > these pages. There is a time where pages are !PageBuddy() and > !PageOffline(). Well, this is fully un...

...and fragile. I post again what I posted before with some further explanations __offline_pages() works like this: 1) start_isolate_page_range() -> offline pages with a reference count of one will be detected as unmovable -> offlining aborted. (see below on the memory isolation notifier) 2) memory_notify(MEM_GOING_OFFLINE, &arg); -> Here, we could release all pages to the buddy, clearing PG_offline -> PF_offline must not be cleared so dumping tools will not touch these pages. There is a time where pages are !PageBuddy() and !PageOffline(). 3) scan_movable_pages() ... 4a) Memory...

On Thu 19-09-19 16:22:25, David Hildenbrand wrote: > virtio-mem wants to allow to offline memory blocks of which some parts > were unplugged, especially, to later offline and remove completely > unplugged memory blocks. The important part is that PageOffline() has > to remain set until the section is offline, so these pages will never > get accessed (e.g., when dumping). The pages

On Thu 19-09-19 16:22:25, David Hildenbrand wrote: > virtio-mem wants to allow to offline memory blocks of which some parts > were unplugged, especially, to later offline and remove completely > unplugged memory blocks. The important part is that PageOffline() has > to remain set until the section is offline, so these pages will never > get accessed (e.g., when dumping). The pages

...(unless the pages are movable, like with balloon compaction). Please note that we have other users that use PG_offline + refcount >= 1 (HyperV balloon, XEN). We should not affect these users (IOW, has_unmovable_pages() has to stop right there if we see one of these pages). > >> 2) memory_notify(MEM_GOING_OFFLINE, &arg); >> -> Here, we could release all pages to the buddy, clearing PG_offline >> -> PF_offline must not be cleared so dumping tools will not touch >> these pages. There is a time where pages are !PageBuddy() and >> !PageOffline(). >...

...via user space). We have to be careful + * with locking when calling add_memory(). + */ +static int virtio_mem_memory_notifier_cb(struct notifier_block *nb, + unsigned long action, void *arg) +{ + struct virtio_mem *vm = container_of(nb, struct virtio_mem, + memory_notifier); + struct memory_notify *mhp = arg; + const unsigned long start = PFN_PHYS(mhp->start_pfn); + const unsigned long size = PFN_PHYS(mhp->nr_pages); + const unsigned long mb_id = virtio_mem_phys_to_mb_id(start); + enum zone_type zone; + int rc = NOTIFY_OK; + + if (!virtio_mem_overlaps_range(vm, start, size)) + return...

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

...p(si_domain, - PFN_PHYS(start_pfn), PFN_PHYS(end_pfn)); + mm_to_dma_pfn(start_pfn), + mm_to_dma_pfn(end_pfn)); if (ret) return ret; } @@ -4593,58 +4585,37 @@ static int intel_iommu_memory_notifier(struct notifier_block *nb, unsigned long val, void *v) { struct memory_notify *mhp = v; - unsigned long long start, end; - unsigned long start_vpfn, last_vpfn; + unsigned long start_vpfn = mm_to_dma_pfn(mhp->start_pfn); + unsigned long last_vpfn = mm_to_dma_pfn(mhp->start_pfn + + mhp->nr_pages - 1); switch (val) { case MEM_GOING_ONLINE: - start = mhp->st...