similar to: [PATCH] virtio-mem: Fix build error due to improper use 'select'

On Fri, Jun 19, 2020 at 04:03:33PM +0800, Weilong Chen wrote: > As noted in: > https://www.kernel.org/doc/Documentation/kbuild/kconfig-language.txt > "select should be used with care. select will force a symbol to a > value without visiting the dependencies." > Config VIRTIO_MEM should not select CONTIG_ALLOC directly. > Otherwise it will cause an error: >

On 19.06.20 10:03, Weilong Chen wrote: > As noted in: > https://www.kernel.org/doc/Documentation/kbuild/kconfig-language.txt > "select should be used with care. select will force a symbol to a > value without visiting the dependencies." Right, rings a bell. > Config VIRTIO_MEM should not select CONTIG_ALLOC directly. > Otherwise it will cause an error: >

Each virtio-mem device owns exactly one memory region. It is responsible for adding/removing memory from that memory region on request. When the device driver starts up, the requested amount of memory is queried and then plugged to Linux. On request, further memory can be plugged or unplugged. This patch only implements the plugging part. On x86-64, memory can currently be plugged in 4MB

On Thu, May 07, 2020 at 12:31:04PM +0200, David Hildenbrand wrote: > 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.

virtio-mem adds memory in memory block granularity, to be able to remove it in the same granularity again later, and to grow slowly on demand. This, however, results in quite a lot of resources when adding a lot of memory. Resources are effectively stored in a list-based tree. Having a lot of resources not only wastes memory, it also makes traversing that tree more expensive, and makes /proc/iomem

rc is initialized to -ENIVAL but that's never used. Drop it. Fixes: 5f1f79bbc9e2 ("virtio-mem: Paravirtualized memory hotplug") Reported-by: kernel test robot <lkp at intel.com> Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/virtio/virtio_mem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/virtio/virtio_mem.c

virtio-mem: add memory via add_memory_driver_managed() On Thu, Jun 11, 2020 at 11:35:18AM +0200, David Hildenbrand wrote: > Virtio-mem managed memory is always detected and added by the virtio-mem > driver, never using something like the firmware-provided memory map. > This is the case after an ordinary system reboot, and has to be guaranteed > after kexec. Especially, virtio-mem

Smatch complains that "rc" can be uninitialized if we hit the "break;" statement on the first iteration through the loop. I suspect that this can't happen in real life, but returning a zero literal is cleaner and silence the static checker warning. Signed-off-by: Dan Carpenter <dan.carpenter at oracle.com> --- drivers/virtio/virtio_mem.c | 2 +- 1 file changed, 1

On Fri, 23 Jun 2023 23:14:39 +0200, Julia Lawall <Julia.Lawall at inria.fr> wrote: > Use array_size to protect against multiplication overflows. > > The changes were done using the following Coccinelle semantic patch: > > // <smpl> > @@ > expression E1, E2; > constant C1, C2; > identifier alloc = {vmalloc,vzalloc}; > @@ > > ( >

Hi David, I love your patch! Yet something to improve: [auto build test ERROR on pm/linux-next] [also build test ERROR on linus/master v5.6-rc4 next-20200302] [cannot apply to linux/master mmotm/master] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system. BTW, we also suggest to use '--base' option to specify the base tree in git

Virtio-mem managed memory is always detected and added by the virtio-mem driver, never using something like the firmware-provided memory map. This is the case after an ordinary system reboot, and has to be guaranteed after kexec. Especially, virtio-mem added memory resources can contain inaccessible parts ("unblocked memory blocks"), blindly forwarding them to a kexec kernel is

Virtio-mem managed memory is always detected and added by the virtio-mem driver, never using something like the firmware-provided memory map. This is the case after an ordinary system reboot, and has to be guaranteed after kexec. Especially, virtio-mem added memory resources can contain inaccessible parts ("unblocked memory blocks"), blindly forwarding them to a kexec kernel is

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().

> Am 24.12.2019 um 08:04 schrieb teawater <teawaterz at linux.alibaba.com>: > > ?Hi David, > > Thanks for your work. > > I Got following build fail if X86_64_ACPI_NUMA is n with rfc3 and rfc4: > make -j8 bzImage > GEN Makefile > DESCEND objtool > CALL /home/teawater/kernel/linux-upstream3/scripts/atomic/check-atomics.sh > CALL

On 11.09.20 22:35, Rikard Falkeborn wrote: > mem_id_table is not modified, so make it const to allow the compiler to > put it in read-only memory. > > Signed-off-by: Rikard Falkeborn <rikard.falkeborn at gmail.com> > --- > drivers/virtio/virtio_mem.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/virtio/virtio_mem.c

On 14.05.20 08:44, teawater wrote: > Hi David, > > I got a kernel warning with v2 and v3. Hi Hui, thanks for playing with the latest versions. Surprisingly, I can reproduce even by hotplugging a DIMM instead as well - that's good, so it's not related to virtio-mem, lol. Seems to be some QEMU setup issue with older machine types. Can you switch to a newer qemu machine version,

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

There's a single commit here that I tweaked since linux-next - the change is in printk format string which I consider trivial enough not force wait for more testing. A couple of hashes are different from what's in linux-next though. I also upgraded the machine I used to sign the tag (didn't change the key) - hope the signature is still ok. If not pls let me know! The following

On 23.05.2018 20:24, David Hildenbrand wrote: > This is the Linux driver side of virtio-mem. Compared to the QEMU side, > it is in a pretty complete and clean state. > > virtio-mem is a paravirtualized mechanism of adding/removing memory to/from > a VM. We can do this on a 4MB granularity right now. In Linux, all > memory is added to the ZONE_NORMAL, so unplugging cannot be

This series is based on latest linux-next. The patches are located at: https://github.com/davidhildenbrand/linux.git virtio-mem-rfc-v4 The basic idea of virtio-mem is to provide a flexible, cross-architecture memory hot(un)plug solution that avoids many limitations imposed by existing technologies, architectures, and interfaces. More details can be found below and in linked material. This