similar to: [v2 1/1] xen, mm: Allow deferred page initialization for xen pv domains

* Pavel Tatashin <pasha.tatashin at oracle.com> wrote: > Juergen Gross noticed that commit > f7f99100d8d ("mm: stop zeroing memory during allocation in vmemmap") > broke XEN PV domains when deferred struct page initialization is enabled. > > This is because the xen's PagePinned() flag is getting erased from struct > pages when they are initialized later in

On 24/02/18 00:25, Pavel Tatashin wrote: > Juergen Gross noticed that commit > f7f99100d8d ("mm: stop zeroing memory during allocation in vmemmap") > broke XEN PV domains when deferred struct page initialization is enabled. > > This is because the xen's PagePinned() flag is getting erased from struct > pages when they are initialized later in boot. > >

(added various kvm/virtualization lists in Cc as well as qemu as I don't know who's "wrong" here) Pavel Tatashin wrote on Thu, Jul 19, 2018: > Allow sched_clock() to be used before schec_clock_init() is called. > This provides with a way to get early boot timestamps on machines with > unstable clocks. This isn't something I understand, but bisect tells me this

On 07.05.20 12:46, Michael S. Tsirkin wrote: > On Thu, May 07, 2020 at 12:31:11PM +0200, David Hildenbrand wrote: >> virtio-mem wants to offline and remove a memory block once it unplugged >> all subblocks (e.g., using alloc_contig_range()). Let's provide >> an interface to do that from a driver. virtio-mem already supports to >> offline partially unplugged memory

virtio-mem wants to offline and remove a memory block once it unplugged all subblocks (e.g., using alloc_contig_range()). Let's provide an interface to do that from a driver. virtio-mem already supports to offline partially unplugged memory blocks. Offlining a fully unplugged memory block will not require to migrate any pages. All unplugged subblocks are PageOffline() and have a reference

virtio-mem wants to offline and remove a memory block once it unplugged all subblocks (e.g., using alloc_contig_range()). Let's provide an interface to do that from a driver. virtio-mem already supports to offline partially unplugged memory blocks. Offlining a fully unplugged memory block will not require to migrate any pages. All unplugged subblocks are PageOffline() and have a reference

virtio-mem wants to offline and remove a memory block once it unplugged all subblocks (e.g., using alloc_contig_range()). Let's provide an interface to do that from a driver. virtio-mem already supports to offline partially unplugged memory blocks. Offlining a fully unplugged memory block will not require to migrate any pages. All unplugged subblocks are PageOffline() and have a reference

virtio-mem wants to offline and remove a memory block once it unplugged all subblocks (e.g., using alloc_contig_range()). Let's provide an interface to do that from a driver. virtio-mem already supports to offline partially unplugged memory blocks. Offlining a fully unplugged memory block will not require to migrate any pages. All unplugged subblocks are PageOffline() and have a reference

Currently, when adding memory, we create entries in /sys/firmware/memmap/ as "System RAM". This does not reflect the reality and will lead to kexec-tools to add that memory to the fixed-up initial memmap for a kexec kernel (loaded via kexec_load()). The memory will be considered initial System RAM by the kexec kernel. We should let the kexec kernel decide how to use that memory - just

Dropping the reference count of PageOffline() pages allows offlining code to skip them. However, we also have to convert PG_reserved to another flag - let's use PG_dirty - so has_unmovable_pages() will properly handle them. PG_reserved pages get detected as unmovable right away. We need the flag to see if we are onlining pages the first time, or if we allocated them via alloc_contig_range().

On Thu, May 07, 2020 at 12:31:11PM +0200, David Hildenbrand wrote: > virtio-mem wants to offline and remove a memory block once it unplugged > all subblocks (e.g., using alloc_contig_range()). Let's provide > an interface to do that from a driver. virtio-mem already supports to > offline partially unplugged memory blocks. Offlining a fully unplugged > memory block will not

On Thu, May 07, 2020 at 12:31:11PM +0200, David Hildenbrand wrote: > virtio-mem wants to offline and remove a memory block once it unplugged > all subblocks (e.g., using alloc_contig_range()). Let's provide > an interface to do that from a driver. virtio-mem already supports to > offline partially unplugged memory blocks. Offlining a fully unplugged > memory block will not

When operating on an unpinned pagetable (ie, one under construction or destruction), it isn''t necessary to use a hypercall to update a pud/pmd entry. Jan Beulich observed that a similar optimisation avoided many thousands of hypercalls while doing a kernel build. One tricky part is that early in the kernel boot there''s no page structure, so we can''t check to see if the

A virtio-mem device wants to allocate memory from the memory region it manages in order to unplug it in the hypervisor - similar to a balloon driver. Also, it might want to plug previously unplugged (allocated) memory and give it back to Linux. alloc_contig_range() / free_contig_range() seem to be the perfect interface for this task. In contrast to existing balloon devices, a virtio-mem device

A virtio-mem device wants to allocate memory from the memory region it manages in order to unplug it in the hypervisor - similar to a balloon driver. Also, it might want to plug previously unplugged (allocated) memory and give it back to Linux. alloc_contig_range() / free_contig_range() seem to be the perfect interface for this task. In contrast to existing balloon devices, a virtio-mem device

On Thu 19-09-19 16:22:23, David Hildenbrand wrote: > A virtio-mem device wants to allocate memory from the memory region it > manages in order to unplug it in the hypervisor - similar to > a balloon driver. Also, it might want to plug previously unplugged > (allocated) memory and give it back to Linux. alloc_contig_range() / > free_contig_range() seem to be the perfect interface for

On Mon 02-03-20 14:49:34, David Hildenbrand wrote: > A virtio-mem device wants to allocate memory from the memory region it > manages in order to unplug it in the hypervisor - similar to > a balloon driver. Also, it might want to plug previously unplugged > (allocated) memory and give it back to Linux. alloc_contig_range() / > free_contig_range() seem to be the perfect interface for

Instead of using six globally visible paravirt ops structures combine them in a single structure, keeping the original structures as sub-structures. This avoids the need to assemble struct paravirt_patch_template at runtime on the stack each time apply_paravirt() is being called (i.e. when loading a module). Signed-off-by: Juergen Gross <jgross at suse.com> --- arch/x86/hyperv/mmu.c

On Mon 02-03-20 14:49:36, David Hildenbrand wrote: > virtio-mem wants to allow to offline memory blocks of which some parts > were unplugged (allocated via alloc_contig_range()), 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

virtio-mem wants to allow to offline memory blocks of which some parts were unplugged (allocated via alloc_contig_range()), 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 should not be handed back to the buddy