Re: [RFC PATCH 10/24] vdpa: introduce config operations for associating ASID to a virtqueue group

On 2020/10/12 下午2:59, Eli Cohen wrote: On Fri, Oct 09, 2020 at 11:56:45AM +0800, Jason Wang wrote: On 2020/10/1 下午9:29, Eli Cohen wrote: On Thu, Sep 24, 2020 at 11:21:11AM +0800, Jason Wang wrote: This patch introduces a new bus operation to allow the vDPA bus driver to associate an ASID to

[PATCH v1 01/29] virtio-mem: determine nid only once using memory_add_physaddr_to_nid()

Let's determine the target nid only once in case we have none specified - usually, we'll end up with node 0 either way. Cc: "Michael S. Tsirkin" Cc: Jason Wang Cc: Pankaj Gupta Signed-off-by: David Hildenbrand --- drivers/virtio/virtio_mem.c | 28 +++- 1 file changed,

[PATCH v1 07/29] virtio-mem: generalize virtio_mem_overlaps_range()

Avoid using memory block ids. While at it, use uint64_t for address/size. Cc: "Michael S. Tsirkin" Cc: Jason Wang Cc: Pankaj Gupta Signed-off-by: David Hildenbrand --- drivers/virtio/virtio_mem.c | 10 +++--- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git

[PATCH v1 08/29] virtio-mem: drop last_mb_id

No longer used, let's drop it. Cc: "Michael S. Tsirkin" Cc: Jason Wang Cc: Pankaj Gupta Signed-off-by: David Hildenbrand --- drivers/virtio/virtio_mem.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/virtio/virtio_mem.c b/drivers/virtio/virtio_mem.c index

[PATCH v1 00/29] virtio-mem: Big Block Mode (BBM)

virtio-mem currently only supports device block sizes that span at most a single Linux memory block. For example, gigantic pages in the hypervisor result on x86-64 in a device block size of 1 GiB - when the Linux memory block size is 128 MiB, we cannot support such devices (we fail loading the

[PATCH v1 03/29] virtio-mem: simplify MAX_ORDER - 1 / pageblock_order handling

Let's use pageblock_nr_pages and MAX_ORDER_NR_PAGES instead where possible, so we don't have do deal with allocation orders. Add a comment why we have that restriction for now. Cc: "Michael S. Tsirkin" Cc: Jason Wang Cc: Pankaj Gupta Signed-off-by: David Hildenbrand ---

[PATCH v1 02/29] virtio-mem: simplify calculation in virtio_mem_mb_state_prepare_next_mb()

We actually need one byte less (next_mb_id is exclusive, first_mb_id is inclusive). Simplify. Cc: "Michael S. Tsirkin" Cc: Jason Wang Cc: Pankaj Gupta Signed-off-by: David Hildenbrand --- drivers/virtio/virtio_mem.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH v1 05/29] virtio-mem: generalize check for added memory

Let's check by traversing busy system RAM resources instead, to avoid relying on memory block states. Don't use walk_system_ram_range(), as that works on pages and we want to use the bare addresses we have easily at hand. Cc: "Michael S. Tsirkin" Cc: Jason Wang Cc: Pankaj Gupta Signed-off-by:

[PATCH v1 04/29] virtio-mem: drop rc2 in virtio_mem_mb_plug_and_add()

We can drop rc2, we don't actually need the value. Cc: "Michael S. Tsirkin" Cc: Jason Wang Cc: Pankaj Gupta Signed-off-by: David Hildenbrand --- drivers/virtio/virtio_mem.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/virtio/virtio_mem.c

[PATCH v1 28/29] virtio-mem: Big Block Mode (BBM) - basic memory hotunplug

Let's try to unplug completely offline big blocks first. Then, (if enabled via unplug_offline) try to offline and remove whole big blocks. No locking necessary - we can deal with concurrent onlining/offlining just fine. Note1: This is sub-optimal and might be dangerous in some environments: we

[PATCH v1 25/29] virtio-mem: Big Block Mode (BBM) memory hotplug

Currently, we do not support device block sizes that exceed the Linux memory block size. For example, having a device block size of 1 GiB (e.g., gigantic pages in the hypervisor) won't work with 128 MiB Linux memory blocks. Let's implement Big Block Mode (BBM), whereby we add/remove at least one

[PATCH v1 26/29] virtio-mem: allow to force Big Block Mode (BBM) and set the big block size

Let's allow to force BBM, even if subblocks would be possible. Take care of properly calculating the first big block id, because the start address might no longer be aligned to the big block size. Also, allow to manually configure the size of Big Blocks. Cc: "Michael S. Tsirkin" Cc: Jason Wang

[PATCH v1 21/29] virtio-mem: memory notifier callbacks are specific to Sub Block Mode (SBM)

Let's rename accordingly. Cc: "Michael S. Tsirkin" Cc: Jason Wang Cc: Pankaj Gupta Signed-off-by: David Hildenbrand --- drivers/virtio/virtio_mem.c | 29 +++-- 1 file changed, 15 insertions(+), 14 deletions(-) diff --git a/drivers/virtio/virtio_mem.c

[PATCH v1 22/29] virtio-mem: memory block ids are specific to Sub Block Mode (SBM)

Let's move first_mb_id/next_mb_id/last_usable_mb_id accordingly. Cc: "Michael S. Tsirkin" Cc: Jason Wang Cc: Pankaj Gupta Signed-off-by: David Hildenbrand --- drivers/virtio/virtio_mem.c | 44 ++--- 1 file changed, 22 insertions(+), 22 deletions(-) diff --git

[PATCH v1 20/29] virtio-mem: nb_sb_per_mb and subblock_size are specific to Sub Block Mode (SBM)

Let's rename to "sbs_per_mb" and "sb_size" and move accordingly. Cc: "Michael S. Tsirkin" Cc: Jason Wang Cc: Pankaj Gupta Signed-off-by: David Hildenbrand --- drivers/virtio/virtio_mem.c | 96 ++--- 1 file changed, 48 insertions(+), 48 deletions(-) diff --git

[PATCH v1 27/29] mm/memory_hotplug: extend offline_and_remove_memory() to handle more than one memory block

virtio-mem soon wants to use offline_and_remove_memory() memory that exceeds a single Linux memory block (memory_block_size_bytes()). Let's remove that restriction. Let's remember the old state and try to restore that if anything goes wrong. While re-onlining can, in general, fail, it's highly

[PATCH v1 24/29] virtio-mem: print debug messages from virtio_mem_send_*_request()

Let's move the existing dev_dbg() into the functions, print if something went wrong, and also print for virtio_mem_send_unplug_all_request(). Cc: "Michael S. Tsirkin" Cc: Jason Wang Cc: Pankaj Gupta Signed-off-by: David Hildenbrand --- drivers/virtio/virtio_mem.c | 50

[PATCH v1 23/29] virtio-mem: factor out adding/removing memory from Linux

Let's use wrappers for the low-level functions that dev_dbg/dev_warn and work on addr + size, such that we can reuse them for adding/removing in other granularity. We only warn when adding memory failed, because that's something to pay attention to. We won't warn when removing failed, we'll reuse

[PATCH v1 29/29] virtio-mem: Big Block Mode (BBM) - safe memory hotunplug

Let's add a safe mechanism to unplug memory, avoiding long/endless loops when trying to offline memory - similar to in SBM. Fake-offline all memory (via alloc_contig_range()) before trying to offline+remove it. Use this mode as default, but allow to enable the other mode explicitly (which could

[PATCH v1 11/29] virtio-mem: use "unsigned long" for nr_pages when fake onlining/offlining

No harm done, but let's be consistent. Cc: "Michael S. Tsirkin" Cc: Jason Wang Cc: Pankaj Gupta Signed-off-by: David Hildenbrand --- drivers/virtio/virtio_mem.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/virtio/virtio_mem.c

[PATCH v1 15/29] virito-mem: document Sub Block Mode (SBM)

Let's add some documentation for the current mode - Sub Block Mode (SBM) - to prepare for a new mode - Big Block Mode (BBM). Follow-up patches will properly factor out the existing Sub Block Mode (SBM) and implement Device Block Mode (DBM). Cc: "Michael S. Tsirkin" Cc: Jason Wang Cc: Pankaj

[PATCH v1 14/29] virtio-mem: retry fake-offlining via alloc_contig_range() on ZONE_MOVABLE

ZONE_MOVABLE is supposed to give some guarantees, yet, alloc_contig_range() isn't prepared to properly deal with some racy cases properly (e.g., temporary page pinning when exiting processed, PCP). Retry 5 times for now. There is certainly room for improvement in the future. Cc: "Michael S.

[PATCH v1 13/29] virtio-mem: factor out handling of fake-offline pages in memory notifier

Let's factor out the core pieces and place the implementation next to virtio_mem_fake_offline(). We'll reuse this functionality soon. Cc: "Michael S. Tsirkin" Cc: Jason Wang Cc: Pankaj Gupta Signed-off-by: David Hildenbrand --- drivers/virtio/virtio_mem.c | 73

[PATCH v1 10/29] virtio-mem: generalize handling when memory is getting onlined deferred

We don't want to add too much memory when it's not getting onlined immediately, to avoid running OOM. Generalize the handling, to avoid making use of memory block states. Use a threshold of 1 GiB for now. Properly adjust the offline size when adding/removing memory. As we are not always protected

[PATCH v1 16/29] virtio-mem: memory block states are specific to Sub Block Mode (SBM)

let's use a new "sbm" sub-struct to hold SBM-specific state and rename + move applicable definitions, frunctions, and variables (related to memory block states). While at it: - Drop the "_STATE" part from memory block states - Rename "nb_mb_state" to "mb_count" - "set_mb_state" / "get_mb_state"

[PATCH v1 17/29] virito-mem: subblock states are specific to Sub Block Mode (SBM)

Let's rename and move accordingly. While at it, rename sb_bitmap to "sb_states". Cc: "Michael S. Tsirkin" Cc: Jason Wang Cc: Pankaj Gupta Signed-off-by: David Hildenbrand --- drivers/virtio/virtio_mem.c | 118 +++- 1 file changed, 62 insertions(+), 56

[PATCH v1 19/29] virito-mem: existing (un)plug functions are specific to Sub Block Mode (SBM)

Let's rename them accordingly. virtio_mem_plug_request() and virtio_mem_unplug_request() will be handled separately. Cc: "Michael S. Tsirkin" Cc: Jason Wang Cc: Pankaj Gupta Signed-off-by: David Hildenbrand --- drivers/virtio/virtio_mem.c | 90 ++--- 1 file

[PATCH v1 18/29] virtio-mem: factor out calculation of the bit number within the sb_states bitmap

The calculation is already complicated enough, let's limit it to one location. Cc: "Michael S. Tsirkin" Cc: Jason Wang Cc: Pankaj Gupta Signed-off-by: David Hildenbrand --- drivers/virtio/virtio_mem.c | 20 +++- 1 file changed, 15 insertions(+), 5 deletions(-) diff --git

[PATCH v1 06/29] virtio-mem: generalize virtio_mem_owned_mb()

Avoid using memory block ids. Rename it to virtio_mem_contains_range(). Cc: "Michael S. Tsirkin" Cc: Jason Wang Cc: Pankaj Gupta Signed-off-by: David Hildenbrand --- drivers/virtio/virtio_mem.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git

[PATCH v1 09/29] virtio-mem: don't always trigger the workqueue when offlining memory

Let's trigger from offlining code when we're not allowed to touch online memory. Handle the other case (memmap possibly freeing up another memory block) when actually removing memory. When removing via virtio_mem_remove(), virtio_mem_retry() is a NOP and safe to use. While at it, move retry

[PATCH v1 12/29] virtio-mem: factor out fake-offlining into virtio_mem_fake_offline()

... which now matches virtio_mem_fake_online(). We'll reuse this functionality soon. Cc: "Michael S. Tsirkin" Cc: Jason Wang Cc: Pankaj Gupta Signed-off-by: David Hildenbrand --- drivers/virtio/virtio_mem.c | 34 -- 1 file changed, 24 insertions(+), 10

Re: [PATCH net-next v3] virtio-net: ethtool configurable RXCSUM

On Sun, Oct 11, 2020 at 10:03 PM wrote: > > From: Tonghao Zhang > > Allow user configuring RXCSUM separately with ethtool -K, > reusing the existing virtnet_set_guest_offloads helper > that configures RXCSUM for XDP. This is conditional on > VIRTIO_NET_F_CTRL_GUEST_OFFLOADS. > > If Rx checksum

Re: [External] Re: [PATCH] mm: proc: add Sock to /proc/meminfo

On 10/12/20 10:39 AM, Muchun Song wrote: > On Mon, Oct 12, 2020 at 3:42 PM Eric Dumazet wrote: >> >> On Mon, Oct 12, 2020 at 6:22 AM Muchun Song wrote: >>> >>> On Mon, Oct 12, 2020 at 2:39 AM Cong Wang wrote: On Sat, Oct 10, 2020 at 3:39 AM Muchun Song wrote: > > The

[PATCH AUTOSEL 5.8 16/24] vhost vdpa: fix vhost_vdpa_open error handling

From: Mike Christie [ Upstream commit 37787e9f81e2e586b526ff5c29c94e4f41513e80 ] We must free the vqs array in the open failure path, because vhost_vdpa_release will not be called. Signed-off-by: Mike Christie Link:

[PATCH v1] drm/virtio: Use UUID API for importing the UUID

There is import_uuid() function which imports u8 array to the uuid_t. Use it instead of open coding variant. This allows to hide the uuid_t internals. Signed-off-by: Andy Shevchenko --- drivers/gpu/drm/virtio/virtgpu_vq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [External] Re: [PATCH] mm: proc: add Sock to /proc/meminfo

On Mon, Oct 12, 2020 at 2:53 AM Muchun Song wrote: > We are not complaining about TCP using too much memory, but how do > we know that TCP uses a lot of memory. When I firstly face this problem, > I do not know who uses the 25GB memory and it is not shown in the > /proc/meminfo. > If we can know

Re: [External] Re: [PATCH] mm: proc: add Sock to /proc/meminfo

On Sun, Oct 11, 2020 at 9:22 PM Muchun Song wrote: > > On Mon, Oct 12, 2020 at 2:39 AM Cong Wang wrote: > > > > On Sat, Oct 10, 2020 at 3:39 AM Muchun Song > > wrote: > > > > > > The amount of memory allocated to sockets buffer can become significant. > > > However, we do not display the

Re: [RFC PATCH 10/24] vdpa: introduce config operations for associating ASID to a virtqueue group

On 2020/10/12 下午4:17, Eli Cohen wrote: On Mon, Oct 12, 2020 at 03:45:10PM +0800, Jason Wang wrote: So in theory we can have several asid's (for different virtqueues), each one should be followed by a specific set_map call. If this is so, how do I know if I met all the conditions run my driver?

Re: [PATCH v2] vdpa/mlx5: Setup driver only if VIRTIO_CONFIG_S_DRIVER_OK

On 2020/9/9 下午1:30, Eli Cohen wrote: On Tue, Sep 08, 2020 at 10:08:39PM -0400, Jason Wang wrote: - Original Message - set_map() is used by mlx5 vdpa to create a memory region based on the address map passed by the iotlb argument. If we get successive calls, we will destroy the