search for: virtio_mem_mb_plug_sb

On Mon, Jun 08, 2020 at 08:58:31AM +0200, David Hildenbrand wrote: > On 08.06.20 08:14, Michael S. Tsirkin wrote: > > 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. > > I fail to see where we could actually trigger an overflow. The reported >

On Mon, Jun 08, 2020 at 08:58:31AM +0200, David Hildenbrand wrote: > On 08.06.20 08:14, Michael S. Tsirkin wrote: > > 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. > > I fail to see where we could actually trigger an overflow. The reported >

...>> I fail to see where we could actually trigger an overflow. The reported >> warning looked like a false positive to me. > > > So > > const uint64_t size = count * vm->subblock_size; > > is it unreasonable for count to be 4K with subblock_size being 1M? virtio_mem_mb_plug_sb() and friends are only called on subblocks residing within a single Linux memory block. (currently, 128MB .. 2G on x86-64). A subblock on x86-64 is currently at least 4MB. So "count * vm->subblock_size" can currently not exceed the Linux memory block size (in practice, it is max 128MB...

...usable region might have shrunk */ + atomic_set(&vm->config_changed, 1); + return 0; + case VIRTIO_MEM_RESP_BUSY: + return -EBUSY; + default: + return -ENOMEM; + } +} + +/* + * Plug selected subblocks. Updates the plugged state, but not the state + * of the memory block. + */ +static int virtio_mem_mb_plug_sb(struct virtio_mem *vm, unsigned long mb_id, + int sb_id, int count) +{ + const uint64_t addr = virtio_mem_mb_id_to_phys(mb_id) + + sb_id * vm->subblock_size; + const uint64_t size = count * vm->subblock_size; + int rc; + + dev_dbg(&vm->vdev->dev, "plugging memory bl...

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

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

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

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

Long time no RFC! I finally had time to get the next version of the Linux driver side of virtio-mem into shape, incorporating ideas and feedback from previous discussions. This RFC is based on the series currently on the mm list: - [PATCH 0/3] Remove __online_page_set_limits() - [PATCH v1 0/3] mm/memory_hotplug: Export generic_online_page() - [PATCH v4 0/8] mm/memory_hotplug: Shrink zones before

This series is based on latest linux-next. The patches are located at: https://github.com/davidhildenbrand/linux.git virtio-mem-v1 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. It's

This series is based on latest linux-next. The patches are located at: https://github.com/davidhildenbrand/linux.git virtio-mem-v1 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. It's