Re: [PATCH net-next v2 0/2] Add sysfs attributes for MANA
On Mon, Apr 29, 2024 at 10:31:38PM -0700, Shradha Gupta wrote: > On Wed, Apr 24, 2024 at 04:48:06PM +0200, Jiri Pirko wrote: > > Wed, Apr 24, 2024 at 12:32:54PM CEST, shradhagu...@linux.microsoft.com > > wrote: > > >These patches include adding sysfs attributes for improving > > >debuggability on MANA devices. > > > > > >The first patch consists on max_mtu, min_mtu attributes that are > > >implemented generically for all devices > > > > > >The second patch has mana specific attributes max_num_msix and num_ports > > > > 1) you implement only max, min is never implemented, no point > > introducing it. > Sure. I had added it for the sake of completeness. > > 2) having driver implement sysfs entry feels *very wrong*, don't do that > > 3) why DEVLINK_PARAM_GENERIC_ID_MSIX_VEC_PER_PF_MAX > >and DEVLINK_PARAM_GENERIC_ID_MSIX_VEC_PER_PF_MIN > >Are not what you want? > Thanks for pointing this out. We are still evaluating if this devlink param > could be used for our usecase where we only need a read-only msix value for > VF. > We keep the thread updated. The attribute that we want is per VF msix max. This is per PF and would not be the right one for our use case. Do you have any other recommendations/suggestions around this? Regards, Shradha. > > > > > > > >Shradha Gupta (2): > > > net: Add sysfs atttributes for max_mtu min_mtu > > > net: mana: Add new device attributes for mana > > > > > > Documentation/ABI/testing/sysfs-class-net | 16 ++ > > > .../net/ethernet/microsoft/mana/gdma_main.c | 32 +++ > > > net/core/net-sysfs.c | 4 +++ > > > 3 files changed, 52 insertions(+) > > > > > >-- > > >2.34.1 > > > > > >
Re: Early kernel panic in dmi_decode when running 32-bit kernel on Hyper-V on Windows 11
Hi Michael, On Thu, 2024-05-02 at 17:02 +, Michael Kelley wrote: > From: Michael Schierl Sent: Friday, April 19, 2024 1:47 PM > > > > > Regardless of the 32-bit vs. 64-bit behavior, the DMI blob is malformed, > > > almost certainly as created by Hyper-V. I'll see if I can bring this to > > > the attention of one of my previous contacts on the Hyper-V team. > > > > FYI, the right people on the Hyper-V team have been informed of the > issue, and there's an internal bug report filed to track the resolution. > I don't have access to the internal bug report, and can't predict when or > how a fix might be made available. But given the impact, they should > be motivated to work on it. Thank you very much for your perseverance, let's see where it goes. -- Jean Delvare SUSE L3 Support
[PATCH v3 1/2] hv_balloon: Use kernel macros to simplify open coded sequences
From: Michael Kelley
Code sequences equivalent to ALIGN(), ALIGN_DOWN(), and umin() are
currently open coded. Change these to use the kernel macro to
improve code clarity. ALIGN() and ALIGN_DOWN() require the
alignment value to be a power of 2, which is the case here.
Reviewed-by: David Hildenbrand
Signed-off-by: Michael Kelley
---
Changes in v3:
* No changes.
Changes in v2:
* No changes. This is a new patch that goes with v2 of patch 2 of this series.
drivers/hv/hv_balloon.c | 40
1 file changed, 8 insertions(+), 32 deletions(-)
diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
index e000fa3b9f97..9f45b8a6762c 100644
--- a/drivers/hv/hv_balloon.c
+++ b/drivers/hv/hv_balloon.c
@@ -729,15 +729,8 @@ static void hv_mem_hot_add(unsigned long start, unsigned
long size,
scoped_guard(spinlock_irqsave, &dm_device.ha_lock) {
has->ha_end_pfn += HA_CHUNK;
-
- if (total_pfn > HA_CHUNK) {
- processed_pfn = HA_CHUNK;
- total_pfn -= HA_CHUNK;
- } else {
- processed_pfn = total_pfn;
- total_pfn = 0;
- }
-
+ processed_pfn = umin(total_pfn, HA_CHUNK);
+ total_pfn -= processed_pfn;
has->covered_end_pfn += processed_pfn;
}
@@ -800,7 +793,7 @@ static int pfn_covered(unsigned long start_pfn, unsigned
long pfn_cnt)
{
struct hv_hotadd_state *has;
struct hv_hotadd_gap *gap;
- unsigned long residual, new_inc;
+ unsigned long residual;
int ret = 0;
guard(spinlock_irqsave)(&dm_device.ha_lock);
@@ -836,15 +829,9 @@ static int pfn_covered(unsigned long start_pfn, unsigned
long pfn_cnt)
* our current limit; extend it.
*/
if ((start_pfn + pfn_cnt) > has->end_pfn) {
+ /* Extend the region by multiples of HA_CHUNK */
residual = (start_pfn + pfn_cnt - has->end_pfn);
- /*
-* Extend the region by multiples of HA_CHUNK.
-*/
- new_inc = (residual / HA_CHUNK) * HA_CHUNK;
- if (residual % HA_CHUNK)
- new_inc += HA_CHUNK;
-
- has->end_pfn += new_inc;
+ has->end_pfn += ALIGN(residual, HA_CHUNK);
}
ret = 1;
@@ -915,9 +902,7 @@ static unsigned long handle_pg_range(unsigned long pg_start,
*/
size = (has->end_pfn - has->ha_end_pfn);
if (pfn_cnt <= size) {
- size = ((pfn_cnt / HA_CHUNK) * HA_CHUNK);
- if (pfn_cnt % HA_CHUNK)
- size += HA_CHUNK;
+ size = ALIGN(pfn_cnt, HA_CHUNK);
} else {
pfn_cnt = size;
}
@@ -1011,9 +996,6 @@ static void hot_add_req(struct work_struct *dummy)
rg_sz = dm->ha_wrk.ha_region_range.finfo.page_cnt;
if ((rg_start == 0) && (!dm->host_specified_ha_region)) {
- unsigned long region_size;
- unsigned long region_start;
-
/*
* The host has not specified the hot-add region.
* Based on the hot-add page range being specified,
@@ -1021,14 +1003,8 @@ static void hot_add_req(struct work_struct *dummy)
* that need to be hot-added while ensuring the alignment
* and size requirements of Linux as it relates to hot-add.
*/
- region_size = (pfn_cnt / HA_CHUNK) * HA_CHUNK;
- if (pfn_cnt % HA_CHUNK)
- region_size += HA_CHUNK;
-
- region_start = (pg_start / HA_CHUNK) * HA_CHUNK;
-
- rg_start = region_start;
- rg_sz = region_size;
+ rg_start = ALIGN_DOWN(pg_start, HA_CHUNK);
+ rg_sz = ALIGN(pfn_cnt, HA_CHUNK);
}
if (do_hot_add)
--
2.25.1
[PATCH v3 2/2] hv_balloon: Enable hot-add for memblock sizes > 128 MiB
From: Michael Kelley
The Hyper-V balloon driver supports hot-add of memory in addition
to ballooning. Current code hot-adds in fixed size chunks of
128 MiB (fixed constant HA_CHUNK in the code). While this works
in Hyper-V VMs with 64 GiB or less or memory where the Linux
memblock size is 128 MiB, the hot-add fails for larger memblock
sizes because add_memory() expects memory to be added in chunks
that match the memblock size. Messages like the following are
reported when Linux has a 256 MiB memblock size:
[ 312.668859] Block size [0x1000] unaligned hotplug range:
start 0x31000, size 0x800
[ 312.668880] hv_balloon: hot_add memory failed error is -22
[ 312.668984] hv_balloon: Memory hot add failed
Larger memblock sizes are usually used in VMs with more than
64 GiB of memory, depending on the alignment of the VM's
physical address space.
Fix this problem by having the Hyper-V balloon driver determine
the Linux memblock size, and process hot-add requests in that
chunk size instead of a fixed 128 MiB. Also update the hot-add
alignment requested of the Hyper-V host to match the memblock
size.
The code changes look significant, but in fact are just a
simple text substitution of a new global variable for the
previous HA_CHUNK constant. No algorithms are changed except
to initialize the new global variable and to calculate the
alignment value to pass to Hyper-V. Testing with memblock
sizes of 256 MiB and 2 GiB shows correct operation.
Reviewed-by: David Hildenbrand
Signed-off-by: Michael Kelley
---
Changes in v3:
* Introduce HA_BYTES_IN_CHUNK and use in two places. [David Hildenbrand]
* Set ha_pages_in_chunk in balloon_probe() instead of init_balloon_drv()
so that memory_block_size_bytes() can be under an existing #ifdef
CONFIG_MEMORY_HOTPLUG [kernel test robot]
Changes in v2:
* Change new global variable name from ha_chunk_pgs to ha_pages_in_chunk
[David Hildenbrand]
* Use kernel macros ALIGN(), ALIGN_DOWN(), and umin() to simplify code
and reduce references to HA_CHUNK. For ease of review, this is done
in a new patch preceeding this one. [David Hildenbrand]
drivers/hv/hv_balloon.c | 64 +++--
1 file changed, 43 insertions(+), 21 deletions(-)
diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
index 9f45b8a6762c..4370ad31b5b3 100644
--- a/drivers/hv/hv_balloon.c
+++ b/drivers/hv/hv_balloon.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
@@ -425,11 +426,11 @@ struct dm_info_msg {
* The range start_pfn : end_pfn specifies the range
* that the host has asked us to hot add. The range
* start_pfn : ha_end_pfn specifies the range that we have
- * currently hot added. We hot add in multiples of 128M
- * chunks; it is possible that we may not be able to bring
- * online all the pages in the region. The range
+ * currently hot added. We hot add in chunks equal to the
+ * memory block size; it is possible that we may not be able
+ * to bring online all the pages in the region. The range
* covered_start_pfn:covered_end_pfn defines the pages that can
- * be brough online.
+ * be brought online.
*/
struct hv_hotadd_state {
@@ -505,8 +506,11 @@ enum hv_dm_state {
static __u8 recv_buffer[HV_HYP_PAGE_SIZE];
static __u8 balloon_up_send_buffer[HV_HYP_PAGE_SIZE];
+
+static unsigned long ha_pages_in_chunk;
+#define HA_BYTES_IN_CHUNK (ha_pages_in_chunk << PAGE_SHIFT)
+
#define PAGES_IN_2M (2 * 1024 * 1024 / PAGE_SIZE)
-#define HA_CHUNK (128 * 1024 * 1024 / PAGE_SIZE)
struct hv_dynmem_device {
struct hv_device *dev;
@@ -724,21 +728,21 @@ static void hv_mem_hot_add(unsigned long start, unsigned
long size,
unsigned long processed_pfn;
unsigned long total_pfn = pfn_count;
- for (i = 0; i < (size/HA_CHUNK); i++) {
- start_pfn = start + (i * HA_CHUNK);
+ for (i = 0; i < (size/ha_pages_in_chunk); i++) {
+ start_pfn = start + (i * ha_pages_in_chunk);
scoped_guard(spinlock_irqsave, &dm_device.ha_lock) {
- has->ha_end_pfn += HA_CHUNK;
- processed_pfn = umin(total_pfn, HA_CHUNK);
+ has->ha_end_pfn += ha_pages_in_chunk;
+ processed_pfn = umin(total_pfn, ha_pages_in_chunk);
total_pfn -= processed_pfn;
- has->covered_end_pfn += processed_pfn;
+ has->covered_end_pfn += processed_pfn;
}
reinit_completion(&dm_device.ol_waitevent);
nid = memory_add_physaddr_to_nid(PFN_PHYS(start_pfn));
ret = add_memory(nid, PFN_PHYS((start_pfn)),
- (HA_CHUNK << PAGE_SHIFT), MHP_MERGE_RESOURCE);
+HA_BYTES_IN_CHUNK, MHP_MERGE_RESOURCE);
if (ret) {
pr_err("hot_add memory failed error is %d\n", ret);
@@ -75
