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

On 2020/6/19 ??4: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." > Config VIRTIO_MEM should not select CONTIG_ALLOC directly. > Otherwise it will cause an error: >

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: >

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

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

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,

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

Let's make sure patches/bug reports find the right person. Cc: "Michael S. Tsirkin" <mst at redhat.com> Signed-off-by: David Hildenbrand <david at redhat.com> --- MAINTAINERS | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 4d43ea5468b5..ad2b34f4dd66 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -18037,6 +18037,13 @@ S:

On Thu, May 07, 2020 at 12:31:14PM +0200, David Hildenbrand wrote: > Let's make sure patches/bug reports find the right person. > > Cc: "Michael S. Tsirkin" <mst at redhat.com> > Signed-off-by: David Hildenbrand <david at redhat.com> Make this patch 2 in the series, or even squash into patch 1. > --- > MAINTAINERS | 7 +++++++ > 1 file changed, 7

Let's add the status/info page, which is still under construction, however, already contains valuable documentation/information. Cc: "Michael S. Tsirkin" <mst at redhat.com> Cc: Pankaj Gupta <pankaj.gupta.linux at gmail.com> Signed-off-by: David Hildenbrand <david at redhat.com> --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS