* Re: [PATCH net-next v4] net: mana: Add MAC address to vPort logs and clarify error messages
From: Erni Sri Satya Vennela @ 2026-03-02 17:27 UTC (permalink / raw)
To: Simon Horman
Cc: kys, haiyangz, wei.liu, decui, longli, andrew+netdev, davem,
edumazet, kuba, pabeni, dipayanroy, shirazsaleem, ssengar,
shradhagupta, gargaditya, linux-hyperv, netdev, linux-kernel
In-Reply-To: <aaRsN8FDf8aH54QB@horms.kernel.org>
> I have reservations about the usefulness of including __func__ and __LINE__
> in debug messages. In a nutshell, it requires the logs to be correlated
> (exactly?) with the source used to build the driver. And at that point
> I think other mechanism - e.g. dynamic trace points - are going to be
> useful if the debug message (without function and line information)
> is insufficient to pinpoint the problem.
>
> This is a general statement, rather than something specifically
> about this code. But nonetheless I'd advise against adding this
> information here.
>
Thankyou Jakub and Simon for the suggestions.
I'll remove both in the next version.
^ permalink raw reply
* [PATCH net-next v5] net: mana: Add MAC address to vPort logs and clarify error messages
From: Erni Sri Satya Vennela @ 2026-03-02 17:41 UTC (permalink / raw)
To: kys, haiyangz, wei.liu, decui, longli, andrew+netdev, davem,
edumazet, kuba, pabeni, dipayanroy, shirazsaleem, kees, ernis,
shradhagupta, gargaditya, linux-hyperv, netdev, linux-kernel
Add MAC address to vPort configuration success message and update error
message to be more specific about HWC message errors in
mana_send_request.
Signed-off-by: Erni Sri Satya Vennela <ernis@linux.microsoft.com>
---
Changes in v5:
* Remove __func__ and __LINE__ from error logs in hw_channel.c
Changes in v4:
* Remove logs that do not add value in hw_channel.c.
Changes in v3:
* Remove the changes from v2 and Update commit message.
* Use "Enabled vPort ..." instead of "Configured vPort" in
mana_cfg_vport.
* Update error logs in mana_hwc_send_request.
Changes in v2:
* Update commit message.
* Use "Enabled vPort ..." instead of "Configured vPort" in
mana_cfg_vport.
* Add info log in mana_uncfg_vport, mana_gd_verify_vf_version,
mana_gd_query_max_resources, mana_query_device_cfg and
mana_query_vport_cfg.
---
drivers/net/ethernet/microsoft/mana/hw_channel.c | 12 +++++++-----
drivers/net/ethernet/microsoft/mana/mana_en.c | 8 ++++----
2 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/microsoft/mana/hw_channel.c b/drivers/net/ethernet/microsoft/mana/hw_channel.c
index ba3467f1e2ea..91975bdb5686 100644
--- a/drivers/net/ethernet/microsoft/mana/hw_channel.c
+++ b/drivers/net/ethernet/microsoft/mana/hw_channel.c
@@ -853,6 +853,7 @@ int mana_hwc_send_request(struct hw_channel_context *hwc, u32 req_len,
struct hwc_caller_ctx *ctx;
u32 dest_vrcq = 0;
u32 dest_vrq = 0;
+ u32 command;
u16 msg_id;
int err;
@@ -878,6 +879,7 @@ int mana_hwc_send_request(struct hw_channel_context *hwc, u32 req_len,
req_msg->req.hwc_msg_id = msg_id;
tx_wr->msg_size = req_len;
+ command = req_msg->req.msg_type;
if (gc->is_pf) {
dest_vrq = hwc->pf_dest_vrq_id;
@@ -893,8 +895,8 @@ int mana_hwc_send_request(struct hw_channel_context *hwc, u32 req_len,
if (!wait_for_completion_timeout(&ctx->comp_event,
(msecs_to_jiffies(hwc->hwc_timeout)))) {
if (hwc->hwc_timeout != 0)
- dev_err(hwc->dev, "HWC: Request timed out: %u ms\n",
- hwc->hwc_timeout);
+ dev_err(hwc->dev, "Command 0x%x timed out: %u ms\n",
+ command, hwc->hwc_timeout);
/* Reduce further waiting if HWC no response */
if (hwc->hwc_timeout > 1)
@@ -914,9 +916,9 @@ int mana_hwc_send_request(struct hw_channel_context *hwc, u32 req_len,
err = -EOPNOTSUPP;
goto out;
}
- if (req_msg->req.msg_type != MANA_QUERY_PHY_STAT)
- dev_err(hwc->dev, "HWC: Failed hw_channel req: 0x%x\n",
- ctx->status_code);
+ if (command != MANA_QUERY_PHY_STAT)
+ dev_err(hwc->dev, "Command 0x%x failed with status: 0x%x\n",
+ command, ctx->status_code);
err = -EPROTO;
goto out;
}
diff --git a/drivers/net/ethernet/microsoft/mana/mana_en.c b/drivers/net/ethernet/microsoft/mana/mana_en.c
index 933e9d681ded..e25d85b38845 100644
--- a/drivers/net/ethernet/microsoft/mana/mana_en.c
+++ b/drivers/net/ethernet/microsoft/mana/mana_en.c
@@ -1021,8 +1021,8 @@ static int mana_send_request(struct mana_context *ac, void *in_buf,
if (req->req.msg_type != MANA_QUERY_PHY_STAT &&
mana_need_log(gc, err))
- dev_err(dev, "Failed to send mana message: %d, 0x%x\n",
- err, resp->status);
+ dev_err(dev, "Command 0x%x failed with status: 0x%x, err: %d\n",
+ req->req.msg_type, resp->status, err);
return err ? err : -EPROTO;
}
@@ -1335,8 +1335,8 @@ int mana_cfg_vport(struct mana_port_context *apc, u32 protection_dom_id,
apc->tx_shortform_allowed = resp.short_form_allowed;
apc->tx_vp_offset = resp.tx_vport_offset;
- netdev_info(apc->ndev, "Configured vPort %llu PD %u DB %u\n",
- apc->port_handle, protection_dom_id, doorbell_pg_id);
+ netdev_info(apc->ndev, "Enabled vPort %llu PD %u DB %u MAC %pM\n",
+ apc->port_handle, protection_dom_id, doorbell_pg_id, apc->mac_addr);
out:
if (err)
mana_uncfg_vport(apc);
--
2.34.1
^ permalink raw reply related
* Re: [PATCH net-next 0/6] net: mana: Per-vPort EQ and MSI-X interrupt management
From: Jakub Kicinski @ 2026-03-03 2:59 UTC (permalink / raw)
To: Long Li
Cc: Konstantin Taranov, David S . Miller, Paolo Abeni, Eric Dumazet,
Andrew Lunn, Jason Gunthorpe, Leon Romanovsky, Haiyang Zhang,
K . Y . Srinivasan, Wei Liu, Dexuan Cui, Simon Horman, netdev,
linux-rdma, linux-hyperv, linux-kernel
In-Reply-To: <20260228021144.85054-1-longli@microsoft.com>
On Fri, 27 Feb 2026 18:11:38 -0800 Long Li wrote:
> This series adds per-vPort Event Queue (EQ) allocation and MSI-X interrupt
> management for the MANA driver. Previously, all vPorts shared a single set
> of EQs. This change enables dedicated EQs per vPort with support for both
> dedicated and shared MSI-X vector allocation modes.
Does not apply to net-next, please rebase.
^ permalink raw reply
* Re: [PATCH v2 1/4] mm/page_reporting: add PAGE_REPORTING_ORDER_UNSPECIFIED
From: Yuvraj Sakshith @ 2026-03-03 8:52 UTC (permalink / raw)
To: David Hildenbrand (Arm)
Cc: akpm, mst, jasowang, kys, haiyangz, wei.liu, decui, linux-mm,
virtualization, linux-hyperv, linux-kernel, xuanzhuo, eperezma,
lorenzo.stoakes, Liam.Howlett, vbabka, rppt, surenb, mhocko,
jackmanb, hannes, ziy
In-Reply-To: <2f14572e-e02b-4bc5-abd2-7814c24f7905@kernel.org>
On Mon, Mar 02, 2026 at 03:57:50PM +0100, David Hildenbrand (Arm) wrote:
> > /* Initialize to an unsupported value */
> > -unsigned int page_reporting_order = -1;
> > +unsigned int page_reporting_order = PAGE_REPORTING_ORDER_UNSPECIFIED;
> >
> > static int page_order_update_notify(const char *val, const struct kernel_param *kp)
> > {
> > @@ -25,12 +25,7 @@ static int page_order_update_notify(const char *val, const struct kernel_param *
> >
> > static const struct kernel_param_ops page_reporting_param_ops = {
> > .set = &page_order_update_notify,
> > - /*
> > - * For the get op, use param_get_int instead of param_get_uint.
> > - * This is to make sure that when unset the initialized value of
> > - * -1 is shown correctly
> > - */
> > - .get = ¶m_get_int,
> > + .get = ¶m_get_uint,
> > };
>
> I think the change to page_reporting_order (and param_get_int) should
> come after patch #4.
>
> Otherwise, you temporarily change the semantics of
> page_reporting_param_ops() etc.
>
> So you should perform the page_reporting_order changes either in patch
> #4 or in a new patch #5.
>
> Apart from that LGTM.
>
> --
> Cheers,
>
> David
Sounds good. Ill add a #5.
Thanks,
Yuvraj
^ permalink raw reply
* [PATCH v3 0/5] Allow order zero pages in page reporting
From: Yuvraj Sakshith @ 2026-03-03 9:33 UTC (permalink / raw)
To: mst, david
Cc: kys, haiyangz, wei.liu, decui, longli, jasowang, xuanzhuo,
eperezma, akpm, lorenzo.stoakes, Liam.Howlett, vbabka, rppt,
surenb, mhocko, jackmanb, hannes, ziy, linux-hyperv, linux-kernel,
virtualization, linux-mm
Today, page reporting sets page_reporting_order in two ways:
(1) page_reporting.page_reporting_order cmdline parameter
(2) Driver can pass order while registering itself.
In both cases, order zero is ignored by free page reporting
because it is used to set page_reporting_order to a default
value, like MAX_PAGE_ORDER.
In some cases we might want page_reporting_order to be zero.
For instance, when virtio-balloon runs inside a guest with
tiny memory (say, 16MB), it might not be able to find a order 1 page
(or in the worst case order MAX_PAGE_ORDER page) after some uptime.
Page reporting should be able to return order zero pages back for
optimal memory relinquishment.
This patch changes the default fallback value from '0' to '-1' in
all possible clients of free page reporting (hv_balloon and
virtio-balloon) together with allowing '0' as a valid order in
page_reporting_register().
Changes in v1:
- Introduce PAGE_REPORTING_DEFAULT_ORDER macro (initially set to 0).
- Make use of new macro in drivers (hv_balloon and virtio-balloon)
working with page reporting.
- Change PAGE_REPORTING_DEFAULT_ORDER to -1 as zero is a valid
page order that can be requested.
Changes in v2:
- Better naming. Replace PAGE_REPORTING_DEFAULT_ORDER with
PAGE_REPORTING_ORDER_UNSPECIFIED. This takes care of
the situation where page reporting order is not specified
in the commandline.
- Minor commit message changes.
Changes in v3:
- Setting page_reporting_order's initial value to
PAGE_REPORTING_ORDER_UNSPECIFIED moved to
PATCH #5.
Yuvraj Sakshith (5):
mm/page_reporting: add PAGE_REPORTING_ORDER_UNSPECIFIED
virtio_balloon: set unspecified page reporting order
hv_balloon: set unspecified page reporting order
mm/page_reporting: change PAGE_REPORTING_ORDER_UNSPECIFIED to -1
mm/page_reporting: change page_reporting_order to
PAGE_REPORTING_ORDER_UNSPECIFIED
drivers/hv/hv_balloon.c | 2 +-
drivers/virtio/virtio_balloon.c | 2 ++
include/linux/page_reporting.h | 1 +
mm/page_reporting.c | 7 ++++---
4 files changed, 8 insertions(+), 4 deletions(-)
--
2.34.1
^ permalink raw reply
* [PATCH v3 1/5] mm/page_reporting: add PAGE_REPORTING_ORDER_UNSPECIFIED
From: Yuvraj Sakshith @ 2026-03-03 9:33 UTC (permalink / raw)
To: mst, david
Cc: kys, haiyangz, wei.liu, decui, longli, jasowang, xuanzhuo,
eperezma, akpm, lorenzo.stoakes, Liam.Howlett, vbabka, rppt,
surenb, mhocko, jackmanb, hannes, ziy, linux-hyperv, linux-kernel,
virtualization, linux-mm
In-Reply-To: <20260303093341.2927482-1-yuvraj.sakshith@oss.qualcomm.com>
Drivers can pass order of pages to be reported while
registering itself. Today, this is a magic number, 0.
Label this with PAGE_REPORTING_ORDER_UNSPECIFIED and
check for it when the driver is being registered.
This macro will be used in relevant drivers next.
Signed-off-by: Yuvraj Sakshith <yuvraj.sakshith@oss.qualcomm.com>
---
include/linux/page_reporting.h | 1 +
mm/page_reporting.c | 5 +++--
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/include/linux/page_reporting.h b/include/linux/page_reporting.h
index fe648dfa3..d1886c657 100644
--- a/include/linux/page_reporting.h
+++ b/include/linux/page_reporting.h
@@ -7,6 +7,7 @@
/* This value should always be a power of 2, see page_reporting_cycle() */
#define PAGE_REPORTING_CAPACITY 32
+#define PAGE_REPORTING_ORDER_UNSPECIFIED 0
struct page_reporting_dev_info {
/* function that alters pages to make them "reported" */
diff --git a/mm/page_reporting.c b/mm/page_reporting.c
index e4c428e61..40a756b60 100644
--- a/mm/page_reporting.c
+++ b/mm/page_reporting.c
@@ -369,8 +369,9 @@ int page_reporting_register(struct page_reporting_dev_info *prdev)
* pageblock_order.
*/
- if (page_reporting_order == -1) {
- if (prdev->order > 0 && prdev->order <= MAX_PAGE_ORDER)
+ if (page_reporting_order == PAGE_REPORTING_ORDER_UNSPECIFIED) {
+ if (prdev->order != PAGE_REPORTING_ORDER_UNSPECIFIED &&
+ prdev->order <= MAX_PAGE_ORDER)
page_reporting_order = prdev->order;
else
page_reporting_order = pageblock_order;
--
2.34.1
^ permalink raw reply related
* [PATCH v3 2/5] virtio_balloon: set unspecified page reporting order
From: Yuvraj Sakshith @ 2026-03-03 9:33 UTC (permalink / raw)
To: mst, david
Cc: kys, haiyangz, wei.liu, decui, longli, jasowang, xuanzhuo,
eperezma, akpm, lorenzo.stoakes, Liam.Howlett, vbabka, rppt,
surenb, mhocko, jackmanb, hannes, ziy, linux-hyperv, linux-kernel,
virtualization, linux-mm
In-Reply-To: <20260303093341.2927482-1-yuvraj.sakshith@oss.qualcomm.com>
virtio_balloon page reporting order is set to MAX_PAGE_ORDER implicitly
as vb->prdev.order is never initialised and is auto-set to zero.
Explicitly mention usage of default page order by making use of
PAGE_REPORTING_ORDER_UNSPECIFIED fallback value.
Acked-by: David Hildenbrand (Arm) <david@kernel.org>
Signed-off-by: Yuvraj Sakshith <yuvraj.sakshith@oss.qualcomm.com>
---
drivers/virtio/virtio_balloon.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 74fe59f5a..2dfe2bcd8 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -1044,6 +1044,8 @@ static int virtballoon_probe(struct virtio_device *vdev)
goto out_unregister_oom;
}
+ vb->pr_dev_info.order = PAGE_REPORTING_ORDER_UNSPECIFIED;
+
/*
* The default page reporting order is @pageblock_order, which
* corresponds to 512MB in size on ARM64 when 64KB base page
--
2.34.1
^ permalink raw reply related
* [PATCH v3 3/5] hv_balloon: set unspecified page reporting order
From: Yuvraj Sakshith @ 2026-03-03 9:33 UTC (permalink / raw)
To: mst, david
Cc: kys, haiyangz, wei.liu, decui, longli, jasowang, xuanzhuo,
eperezma, akpm, lorenzo.stoakes, Liam.Howlett, vbabka, rppt,
surenb, mhocko, jackmanb, hannes, ziy, linux-hyperv, linux-kernel,
virtualization, linux-mm
In-Reply-To: <20260303093341.2927482-1-yuvraj.sakshith@oss.qualcomm.com>
Explicitly mention page reporting order to be set to
default value using PAGE_REPORTING_ORDER_UNSPECIFIED fallback
value.
Acked-by: David Hildenbrand (Arm) <david@kernel.org>
Signed-off-by: Yuvraj Sakshith <yuvraj.sakshith@oss.qualcomm.com>
---
drivers/hv/hv_balloon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
index 2b4080e51..09da68101 100644
--- a/drivers/hv/hv_balloon.c
+++ b/drivers/hv/hv_balloon.c
@@ -1663,7 +1663,7 @@ static void enable_page_reporting(void)
* We let the page_reporting_order parameter decide the order
* in the page_reporting code
*/
- dm_device.pr_dev_info.order = 0;
+ dm_device.pr_dev_info.order = PAGE_REPORTING_ORDER_UNSPECIFIED;
ret = page_reporting_register(&dm_device.pr_dev_info);
if (ret < 0) {
dm_device.pr_dev_info.report = NULL;
--
2.34.1
^ permalink raw reply related
* [PATCH v3 4/5] mm/page_reporting: change PAGE_REPORTING_ORDER_UNSPECIFIED to -1
From: Yuvraj Sakshith @ 2026-03-03 9:33 UTC (permalink / raw)
To: mst, david
Cc: kys, haiyangz, wei.liu, decui, longli, jasowang, xuanzhuo,
eperezma, akpm, lorenzo.stoakes, Liam.Howlett, vbabka, rppt,
surenb, mhocko, jackmanb, hannes, ziy, linux-hyperv, linux-kernel,
virtualization, linux-mm
In-Reply-To: <20260303093341.2927482-1-yuvraj.sakshith@oss.qualcomm.com>
PAGE_REPORTING_ORDER_UNSPECIFIED is now set to zero. This means,
pages of order zero cannot be reported to a client/driver -- as zero
is used to signal a fallback to MAX_PAGE_ORDER.
Change PAGE_REPORTING_ORDER_UNSPECIFIED to (-1),
so that zero can be used as a valid order with which pages can
be reported.
Signed-off-by: Yuvraj Sakshith <yuvraj.sakshith@oss.qualcomm.com>
---
include/linux/page_reporting.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/page_reporting.h b/include/linux/page_reporting.h
index d1886c657..9d4ca5c21 100644
--- a/include/linux/page_reporting.h
+++ b/include/linux/page_reporting.h
@@ -7,7 +7,7 @@
/* This value should always be a power of 2, see page_reporting_cycle() */
#define PAGE_REPORTING_CAPACITY 32
-#define PAGE_REPORTING_ORDER_UNSPECIFIED 0
+#define PAGE_REPORTING_ORDER_UNSPECIFIED -1
struct page_reporting_dev_info {
/* function that alters pages to make them "reported" */
--
2.34.1
^ permalink raw reply related
* [PATCH v3 5/5] mm/page_reporting: change page_reporting_order to PAGE_REPORTING_ORDER_UNSPECIFIED
From: Yuvraj Sakshith @ 2026-03-03 9:33 UTC (permalink / raw)
To: mst, david
Cc: kys, haiyangz, wei.liu, decui, longli, jasowang, xuanzhuo,
eperezma, akpm, lorenzo.stoakes, Liam.Howlett, vbabka, rppt,
surenb, mhocko, jackmanb, hannes, ziy, linux-hyperv, linux-kernel,
virtualization, linux-mm
In-Reply-To: <20260303093341.2927482-1-yuvraj.sakshith@oss.qualcomm.com>
page_reporting_order when uninitialised, holds a magic number -1.
Since we now maintain PAGE_REPORTING_ORDER_UNSPECIFIED as -1, which
is also a flag, set page_reporting_order to this flag.
Signed-off-by: Yuvraj Sakshith <yuvraj.sakshith@oss.qualcomm.com>
---
mm/page_reporting.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/page_reporting.c b/mm/page_reporting.c
index 40a756b60..21c11b75e 100644
--- a/mm/page_reporting.c
+++ b/mm/page_reporting.c
@@ -12,7 +12,7 @@
#include "internal.h"
/* Initialize to an unsupported value */
-unsigned int page_reporting_order = -1;
+unsigned int page_reporting_order = PAGE_REPORTING_ORDER_UNSPECIFIED;
static int page_order_update_notify(const char *val, const struct kernel_param *kp)
{
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v3 1/5] mm/page_reporting: add PAGE_REPORTING_ORDER_UNSPECIFIED
From: David Hildenbrand (Arm) @ 2026-03-03 10:04 UTC (permalink / raw)
To: Yuvraj Sakshith, mst
Cc: kys, haiyangz, wei.liu, decui, longli, jasowang, xuanzhuo,
eperezma, akpm, lorenzo.stoakes, Liam.Howlett, vbabka, rppt,
surenb, mhocko, jackmanb, hannes, ziy, linux-hyperv, linux-kernel,
virtualization, linux-mm
In-Reply-To: <20260303093341.2927482-2-yuvraj.sakshith@oss.qualcomm.com>
On 3/3/26 10:33, Yuvraj Sakshith wrote:
> Drivers can pass order of pages to be reported while
> registering itself. Today, this is a magic number, 0.
>
> Label this with PAGE_REPORTING_ORDER_UNSPECIFIED and
> check for it when the driver is being registered.
>
> This macro will be used in relevant drivers next.
>
> Signed-off-by: Yuvraj Sakshith <yuvraj.sakshith@oss.qualcomm.com>
> ---
> include/linux/page_reporting.h | 1 +
> mm/page_reporting.c | 5 +++--
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/page_reporting.h b/include/linux/page_reporting.h
> index fe648dfa3..d1886c657 100644
> --- a/include/linux/page_reporting.h
> +++ b/include/linux/page_reporting.h
> @@ -7,6 +7,7 @@
>
> /* This value should always be a power of 2, see page_reporting_cycle() */
> #define PAGE_REPORTING_CAPACITY 32
> +#define PAGE_REPORTING_ORDER_UNSPECIFIED 0
>
> struct page_reporting_dev_info {
> /* function that alters pages to make them "reported" */
> diff --git a/mm/page_reporting.c b/mm/page_reporting.c
> index e4c428e61..40a756b60 100644
> --- a/mm/page_reporting.c
> +++ b/mm/page_reporting.c
> @@ -369,8 +369,9 @@ int page_reporting_register(struct page_reporting_dev_info *prdev)
> * pageblock_order.
> */
>
> - if (page_reporting_order == -1) {
> - if (prdev->order > 0 && prdev->order <= MAX_PAGE_ORDER)
> + if (page_reporting_order == PAGE_REPORTING_ORDER_UNSPECIFIED) {
This change must also go to #5.
> + if (prdev->order != PAGE_REPORTING_ORDER_UNSPECIFIED &&
> + prdev->order <= MAX_PAGE_ORDER)
> page_reporting_order = prdev->order;
> else
> page_reporting_order = pageblock_order;
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH v3 4/5] mm/page_reporting: change PAGE_REPORTING_ORDER_UNSPECIFIED to -1
From: David Hildenbrand (Arm) @ 2026-03-03 10:04 UTC (permalink / raw)
To: Yuvraj Sakshith, mst
Cc: kys, haiyangz, wei.liu, decui, longli, jasowang, xuanzhuo,
eperezma, akpm, lorenzo.stoakes, Liam.Howlett, vbabka, rppt,
surenb, mhocko, jackmanb, hannes, ziy, linux-hyperv, linux-kernel,
virtualization, linux-mm
In-Reply-To: <20260303093341.2927482-5-yuvraj.sakshith@oss.qualcomm.com>
On 3/3/26 10:33, Yuvraj Sakshith wrote:
> PAGE_REPORTING_ORDER_UNSPECIFIED is now set to zero. This means,
> pages of order zero cannot be reported to a client/driver -- as zero
> is used to signal a fallback to MAX_PAGE_ORDER.
>
> Change PAGE_REPORTING_ORDER_UNSPECIFIED to (-1),
> so that zero can be used as a valid order with which pages can
> be reported.
>
> Signed-off-by: Yuvraj Sakshith <yuvraj.sakshith@oss.qualcomm.com>
> ---
Acked-by: David Hildenbrand (Arm) <david@kernel.org>
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH net-next, v2] net: mana: Trigger VF reset/recovery on health check failure due to HWC timeout
From: patchwork-bot+netdevbpf @ 2026-03-03 10:30 UTC (permalink / raw)
To: Dipayaan Roy
Cc: kys, haiyangz, wei.liu, decui, andrew+netdev, davem, edumazet,
kuba, pabeni, leon, longli, kotaranov, horms, shradhagupta,
ssengar, ernis, shirazsaleem, linux-hyperv, netdev, linux-kernel,
linux-rdma, dipayanroy
In-Reply-To: <aaFShvKnwR5FY8dH@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
Hello:
This patch was applied to netdev/net-next.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Fri, 27 Feb 2026 00:15:02 -0800 you wrote:
> The GF stats periodic query is used as mechanism to monitor HWC health
> check. If this HWC command times out, it is a strong indication that
> the device/SoC is in a faulty state and requires recovery.
>
> Today, when a timeout is detected, the driver marks
> hwc_timeout_occurred, clears cached stats, and stops rescheduling the
> periodic work. However, the device itself is left in the same failing
> state.
>
> [...]
Here is the summary with links:
- [net-next,v2] net: mana: Trigger VF reset/recovery on health check failure due to HWC timeout
https://git.kernel.org/netdev/net-next/c/2b12ffb66955
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next] net: mana: Force full-page RX buffers for 4K page size on specific systems.
From: Paolo Abeni @ 2026-03-03 10:56 UTC (permalink / raw)
To: Dipayaan Roy, kys, haiyangz, wei.liu, decui, andrew+netdev, davem,
edumazet, kuba, leon, longli, kotaranov, horms, shradhagupta,
ssengar, ernis, shirazsaleem, linux-hyperv, netdev, linux-kernel,
linux-rdma, dipayanroy
In-Reply-To: <aaFusIxdbVkUqIpd@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
On 2/27/26 11:15 AM, Dipayaan Roy wrote:
> On certain systems configured with 4K PAGE_SIZE, utilizing page_pool
> fragments for RX buffers results in a significant throughput regression.
> Profiling reveals that this regression correlates with high overhead in the
> fragment allocation and reference counting paths on these specific
> platforms, rendering the multi-buffer-per-page strategy counterproductive.
>
> To mitigate this, bypass the page_pool fragment path and force a single RX
> packet per page allocation when all the following conditions are met:
> 1. The system is configured with a 4K PAGE_SIZE.
> 2. A processor-specific quirk is detected via SMBIOS Type 4 data.
>
> This approach restores expected line-rate performance by ensuring
> predictable RX refill behavior on affected hardware.
>
> There is no behavioral change for systems using larger page sizes
> (16K/64K), or platforms where this processor-specific quirk do not
> apply.
>
> Signed-off-by: Dipayaan Roy <dipayanroy@linux.microsoft.com>
> ---
> .../net/ethernet/microsoft/mana/gdma_main.c | 120 ++++++++++++++++++
> drivers/net/ethernet/microsoft/mana/mana_en.c | 23 +++-
> include/net/mana/gdma.h | 10 ++
> 3 files changed, 151 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/microsoft/mana/gdma_main.c b/drivers/net/ethernet/microsoft/mana/gdma_main.c
> index 0055c231acf6..26bbe736a770 100644
> --- a/drivers/net/ethernet/microsoft/mana/gdma_main.c
> +++ b/drivers/net/ethernet/microsoft/mana/gdma_main.c
> @@ -9,6 +9,7 @@
> #include <linux/msi.h>
> #include <linux/irqdomain.h>
> #include <linux/export.h>
> +#include <linux/dmi.h>
>
> #include <net/mana/mana.h>
> #include <net/mana/hw_channel.h>
> @@ -1955,6 +1956,115 @@ static bool mana_is_pf(unsigned short dev_id)
> return dev_id == MANA_PF_DEVICE_ID;
> }
>
> +/*
> + * Table for Processor Version strings found from SMBIOS Type 4 information,
> + * for processors that needs to force single RX buffer per page quirk for
> + * meeting line rate performance with ARM64 + 4K pages.
> + * Note: These strings are exactly matched with version fetched from SMBIOS.
> + */
> +static const char * const mana_single_rxbuf_per_page_quirk_tbl[] = {
> + "Cobalt 200",
> +};
> +
> +static const char *smbios_get_string(const struct dmi_header *hdr, u8 idx)
> +{
> + const u8 *start, *end;
> + u8 i;
> +
> + /* Indexing starts from 1. */
> + if (!idx)
> + return NULL;
> +
> + start = (const u8 *)hdr + hdr->length;
> + end = start + SMBIOS_STR_AREA_MAX;
> +
> + for (i = 1; i < idx; i++) {
> + while (start < end && *start)
> + start++;
> + if (start < end)
> + start++;
> + if (start + 1 < end && start[0] == 0 && start[1] == 0)
> + return NULL;
> + }
> +
> + if (start >= end || *start == 0)
> + return NULL;
> +
> + return (const char *)start;
If I read correctly, the above sort of duplicate dmi_decode_table().
I think you are better of:
- use the mana_get_proc_ver_from_smbios() decoder to store the
SMBIOS_TYPE4_PROC_VERSION_OFFSET index into gd
- do a 2nd walk with a different decoder to fetch the string at the
specified index.
/P
^ permalink raw reply
* [PATCH v4 0/5] Allow order zero pages in page reporting
From: Yuvraj Sakshith @ 2026-03-03 11:30 UTC (permalink / raw)
To: mst, david
Cc: kys, haiyangz, wei.liu, decui, longli, jasowang, xuanzhuo,
eperezma, akpm, lorenzo.stoakes, Liam.Howlett, vbabka, rppt,
surenb, mhocko, jackmanb, hannes, ziy, linux-hyperv, linux-kernel,
virtualization, linux-mm
Today, page reporting sets page_reporting_order in two ways:
(1) page_reporting.page_reporting_order cmdline parameter
(2) Driver can pass order while registering itself.
In both cases, order zero is ignored by free page reporting
because it is used to set page_reporting_order to a default
value, like MAX_PAGE_ORDER.
In some cases we might want page_reporting_order to be zero.
For instance, when virtio-balloon runs inside a guest with
tiny memory (say, 16MB), it might not be able to find a order 1 page
(or in the worst case order MAX_PAGE_ORDER page) after some uptime.
Page reporting should be able to return order zero pages back for
optimal memory relinquishment.
This patch changes the default fallback value from '0' to '-1' in
all possible clients of free page reporting (hv_balloon and
virtio-balloon) together with allowing '0' as a valid order in
page_reporting_register().
Changes in v1:
- Introduce PAGE_REPORTING_DEFAULT_ORDER macro (initially set to 0).
- Make use of new macro in drivers (hv_balloon and virtio-balloon)
working with page reporting.
- Change PAGE_REPORTING_DEFAULT_ORDER to -1 as zero is a valid
page order that can be requested.
Changes in v2:
- Better naming. Replace PAGE_REPORTING_DEFAULT_ORDER with
PAGE_REPORTING_ORDER_UNSPECIFIED. This takes care of
the situation where page reporting order is not specified
in the commandline.
- Minor commit message changes.
Changes in v3:
- Setting page_reporting_order's initial value to
PAGE_REPORTING_ORDER_UNSPECIFIED moved to
PATCH #5.
Changes in v4:
- Move PAGE_REPORTING_ORDER_UNSPECIFIED's usage with
page_reporting_order to patch #5.
Yuvraj Sakshith (5):
mm/page_reporting: add PAGE_REPORTING_ORDER_UNSPECIFIED
virtio_balloon: set unspecified page reporting order
hv_balloon: set unspecified page reporting order
mm/page_reporting: change PAGE_REPORTING_ORDER_UNSPECIFIED to -1
mm/page_reporting: change page_reporting_order to
PAGE_REPORTING_ORDER_UNSPECIFIED
drivers/hv/hv_balloon.c | 2 +-
drivers/virtio/virtio_balloon.c | 2 ++
include/linux/page_reporting.h | 1 +
mm/page_reporting.c | 7 ++++---
4 files changed, 8 insertions(+), 4 deletions(-)
--
2.34.1
^ permalink raw reply
* [PATCH v4 1/5] mm/page_reporting: add PAGE_REPORTING_ORDER_UNSPECIFIED
From: Yuvraj Sakshith @ 2026-03-03 11:30 UTC (permalink / raw)
To: mst, david
Cc: kys, haiyangz, wei.liu, decui, longli, jasowang, xuanzhuo,
eperezma, akpm, lorenzo.stoakes, Liam.Howlett, vbabka, rppt,
surenb, mhocko, jackmanb, hannes, ziy, linux-hyperv, linux-kernel,
virtualization, linux-mm
In-Reply-To: <20260303113032.3008371-1-yuvraj.sakshith@oss.qualcomm.com>
Drivers can pass order of pages to be reported while
registering itself. Today, this is a magic number, 0.
Label this with PAGE_REPORTING_ORDER_UNSPECIFIED and
check for it when the driver is being registered.
This macro will be used in relevant drivers next.
Signed-off-by: Yuvraj Sakshith <yuvraj.sakshith@oss.qualcomm.com>
---
include/linux/page_reporting.h | 1 +
mm/page_reporting.c | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/linux/page_reporting.h b/include/linux/page_reporting.h
index fe648dfa3..d1886c657 100644
--- a/include/linux/page_reporting.h
+++ b/include/linux/page_reporting.h
@@ -7,6 +7,7 @@
/* This value should always be a power of 2, see page_reporting_cycle() */
#define PAGE_REPORTING_CAPACITY 32
+#define PAGE_REPORTING_ORDER_UNSPECIFIED 0
struct page_reporting_dev_info {
/* function that alters pages to make them "reported" */
diff --git a/mm/page_reporting.c b/mm/page_reporting.c
index e4c428e61..a97ee07cb 100644
--- a/mm/page_reporting.c
+++ b/mm/page_reporting.c
@@ -370,7 +370,8 @@ int page_reporting_register(struct page_reporting_dev_info *prdev)
*/
if (page_reporting_order == -1) {
- if (prdev->order > 0 && prdev->order <= MAX_PAGE_ORDER)
+ if (prdev->order != PAGE_REPORTING_ORDER_UNSPECIFIED &&
+ prdev->order <= MAX_PAGE_ORDER)
page_reporting_order = prdev->order;
else
page_reporting_order = pageblock_order;
--
2.34.1
^ permalink raw reply related
* [PATCH v4 2/5] virtio_balloon: set unspecified page reporting order
From: Yuvraj Sakshith @ 2026-03-03 11:30 UTC (permalink / raw)
To: mst, david
Cc: kys, haiyangz, wei.liu, decui, longli, jasowang, xuanzhuo,
eperezma, akpm, lorenzo.stoakes, Liam.Howlett, vbabka, rppt,
surenb, mhocko, jackmanb, hannes, ziy, linux-hyperv, linux-kernel,
virtualization, linux-mm
In-Reply-To: <20260303113032.3008371-1-yuvraj.sakshith@oss.qualcomm.com>
virtio_balloon page reporting order is set to MAX_PAGE_ORDER implicitly
as vb->prdev.order is never initialised and is auto-set to zero.
Explicitly mention usage of default page order by making use of
PAGE_REPORTING_ORDER_UNSPECIFIED fallback value.
Acked-by: David Hildenbrand (Arm) <david@kernel.org>
Signed-off-by: Yuvraj Sakshith <yuvraj.sakshith@oss.qualcomm.com>
---
drivers/virtio/virtio_balloon.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 74fe59f5a..2dfe2bcd8 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -1044,6 +1044,8 @@ static int virtballoon_probe(struct virtio_device *vdev)
goto out_unregister_oom;
}
+ vb->pr_dev_info.order = PAGE_REPORTING_ORDER_UNSPECIFIED;
+
/*
* The default page reporting order is @pageblock_order, which
* corresponds to 512MB in size on ARM64 when 64KB base page
--
2.34.1
^ permalink raw reply related
* [PATCH v4 3/5] hv_balloon: set unspecified page reporting order
From: Yuvraj Sakshith @ 2026-03-03 11:30 UTC (permalink / raw)
To: mst, david
Cc: kys, haiyangz, wei.liu, decui, longli, jasowang, xuanzhuo,
eperezma, akpm, lorenzo.stoakes, Liam.Howlett, vbabka, rppt,
surenb, mhocko, jackmanb, hannes, ziy, linux-hyperv, linux-kernel,
virtualization, linux-mm
In-Reply-To: <20260303113032.3008371-1-yuvraj.sakshith@oss.qualcomm.com>
Explicitly mention page reporting order to be set to
default value using PAGE_REPORTING_ORDER_UNSPECIFIED fallback
value.
Acked-by: David Hildenbrand (Arm) <david@kernel.org>
Signed-off-by: Yuvraj Sakshith <yuvraj.sakshith@oss.qualcomm.com>
---
drivers/hv/hv_balloon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
index 2b4080e51..09da68101 100644
--- a/drivers/hv/hv_balloon.c
+++ b/drivers/hv/hv_balloon.c
@@ -1663,7 +1663,7 @@ static void enable_page_reporting(void)
* We let the page_reporting_order parameter decide the order
* in the page_reporting code
*/
- dm_device.pr_dev_info.order = 0;
+ dm_device.pr_dev_info.order = PAGE_REPORTING_ORDER_UNSPECIFIED;
ret = page_reporting_register(&dm_device.pr_dev_info);
if (ret < 0) {
dm_device.pr_dev_info.report = NULL;
--
2.34.1
^ permalink raw reply related
* [PATCH v4 4/5] mm/page_reporting: change PAGE_REPORTING_ORDER_UNSPECIFIED to -1
From: Yuvraj Sakshith @ 2026-03-03 11:30 UTC (permalink / raw)
To: mst, david
Cc: kys, haiyangz, wei.liu, decui, longli, jasowang, xuanzhuo,
eperezma, akpm, lorenzo.stoakes, Liam.Howlett, vbabka, rppt,
surenb, mhocko, jackmanb, hannes, ziy, linux-hyperv, linux-kernel,
virtualization, linux-mm
In-Reply-To: <20260303113032.3008371-1-yuvraj.sakshith@oss.qualcomm.com>
PAGE_REPORTING_ORDER_UNSPECIFIED is now set to zero. This means,
pages of order zero cannot be reported to a client/driver -- as zero
is used to signal a fallback to MAX_PAGE_ORDER.
Change PAGE_REPORTING_ORDER_UNSPECIFIED to (-1),
so that zero can be used as a valid order with which pages can
be reported.
Acked-by: David Hildenbrand (Arm) <david@kernel.org>
Signed-off-by: Yuvraj Sakshith <yuvraj.sakshith@oss.qualcomm.com>
---
include/linux/page_reporting.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/page_reporting.h b/include/linux/page_reporting.h
index d1886c657..9d4ca5c21 100644
--- a/include/linux/page_reporting.h
+++ b/include/linux/page_reporting.h
@@ -7,7 +7,7 @@
/* This value should always be a power of 2, see page_reporting_cycle() */
#define PAGE_REPORTING_CAPACITY 32
-#define PAGE_REPORTING_ORDER_UNSPECIFIED 0
+#define PAGE_REPORTING_ORDER_UNSPECIFIED -1
struct page_reporting_dev_info {
/* function that alters pages to make them "reported" */
--
2.34.1
^ permalink raw reply related
* [PATCH v4 5/5] mm/page_reporting: change page_reporting_order to PAGE_REPORTING_ORDER_UNSPECIFIED
From: Yuvraj Sakshith @ 2026-03-03 11:30 UTC (permalink / raw)
To: mst, david
Cc: kys, haiyangz, wei.liu, decui, longli, jasowang, xuanzhuo,
eperezma, akpm, lorenzo.stoakes, Liam.Howlett, vbabka, rppt,
surenb, mhocko, jackmanb, hannes, ziy, linux-hyperv, linux-kernel,
virtualization, linux-mm
In-Reply-To: <20260303113032.3008371-1-yuvraj.sakshith@oss.qualcomm.com>
page_reporting_order when uninitialised, holds a magic number -1.
Since we now maintain PAGE_REPORTING_ORDER_UNSPECIFIED as -1, which
is also a flag, set page_reporting_order to this flag.
Signed-off-by: Yuvraj Sakshith <yuvraj.sakshith@oss.qualcomm.com>
---
mm/page_reporting.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/page_reporting.c b/mm/page_reporting.c
index a97ee07cb..21c11b75e 100644
--- a/mm/page_reporting.c
+++ b/mm/page_reporting.c
@@ -12,7 +12,7 @@
#include "internal.h"
/* Initialize to an unsupported value */
-unsigned int page_reporting_order = -1;
+unsigned int page_reporting_order = PAGE_REPORTING_ORDER_UNSPECIFIED;
static int page_order_update_notify(const char *val, const struct kernel_param *kp)
{
@@ -369,7 +369,7 @@ int page_reporting_register(struct page_reporting_dev_info *prdev)
* pageblock_order.
*/
- if (page_reporting_order == -1) {
+ if (page_reporting_order == PAGE_REPORTING_ORDER_UNSPECIFIED) {
if (prdev->order != PAGE_REPORTING_ORDER_UNSPECIFIED &&
prdev->order <= MAX_PAGE_ORDER)
page_reporting_order = prdev->order;
--
2.34.1
^ permalink raw reply related
* Re: [PATCH net-next] net: mana: Force full-page RX buffers for 4K page size on specific systems.
From: Paolo Abeni @ 2026-03-03 11:56 UTC (permalink / raw)
To: Dipayaan Roy, kys, haiyangz, wei.liu, decui, andrew+netdev, davem,
edumazet, kuba, leon, longli, kotaranov, horms, shradhagupta,
ssengar, ernis, shirazsaleem, linux-hyperv, netdev, linux-kernel,
linux-rdma, dipayanroy
In-Reply-To: <aaFusIxdbVkUqIpd@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
On 2/27/26 11:15 AM, Dipayaan Roy wrote:
> diff --git a/drivers/net/ethernet/microsoft/mana/mana_en.c b/drivers/net/ethernet/microsoft/mana/mana_en.c
> index 91c418097284..a53a8921050b 100644
> --- a/drivers/net/ethernet/microsoft/mana/mana_en.c
> +++ b/drivers/net/ethernet/microsoft/mana/mana_en.c
> @@ -748,6 +748,26 @@ static void *mana_get_rxbuf_pre(struct mana_rxq *rxq, dma_addr_t *da)
> return va;
> }
>
> +static inline bool
> +mana_use_single_rxbuf_per_page(struct mana_port_context *apc, u32 mtu)
> +{
I almost forgot: please avoid the 'inline' keyword in .c files. This is
function used only once, should be inlined by the compiler anyway.
> + struct gdma_context *gc = apc->ac->gdma_dev->gdma_context;
> +
> + /* On some systems with 4K PAGE_SIZE, page_pool RX fragments can
> + * trigger a throughput regression. Hence forces one RX buffer per page
> + * to avoid the fragment allocation/refcounting overhead in the RX
> + * refill path for those processors only.
> + */
> + if (gc->force_full_page_rx_buffer)
> + return true;
Side note: since you could keep the above flag up2date according to the
current mtu and xdp configuration and just test it in the data path.
/P
^ permalink raw reply
* Re: [PATCH v4 1/5] mm/page_reporting: add PAGE_REPORTING_ORDER_UNSPECIFIED
From: David Hildenbrand (Arm) @ 2026-03-03 14:57 UTC (permalink / raw)
To: Yuvraj Sakshith, mst
Cc: kys, haiyangz, wei.liu, decui, longli, jasowang, xuanzhuo,
eperezma, akpm, lorenzo.stoakes, Liam.Howlett, vbabka, rppt,
surenb, mhocko, jackmanb, hannes, ziy, linux-hyperv, linux-kernel,
virtualization, linux-mm
In-Reply-To: <20260303113032.3008371-2-yuvraj.sakshith@oss.qualcomm.com>
On 3/3/26 12:30, Yuvraj Sakshith wrote:
> Drivers can pass order of pages to be reported while
> registering itself. Today, this is a magic number, 0.
>
> Label this with PAGE_REPORTING_ORDER_UNSPECIFIED and
> check for it when the driver is being registered.
>
> This macro will be used in relevant drivers next.
>
> Signed-off-by: Yuvraj Sakshith <yuvraj.sakshith@oss.qualcomm.com>
> ---
> include/linux/page_reporting.h | 1 +
> mm/page_reporting.c | 3 ++-
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/page_reporting.h b/include/linux/page_reporting.h
> index fe648dfa3..d1886c657 100644
> --- a/include/linux/page_reporting.h
> +++ b/include/linux/page_reporting.h
> @@ -7,6 +7,7 @@
>
> /* This value should always be a power of 2, see page_reporting_cycle() */
> #define PAGE_REPORTING_CAPACITY 32
> +#define PAGE_REPORTING_ORDER_UNSPECIFIED 0
>
> struct page_reporting_dev_info {
> /* function that alters pages to make them "reported" */
> diff --git a/mm/page_reporting.c b/mm/page_reporting.c
> index e4c428e61..a97ee07cb 100644
> --- a/mm/page_reporting.c
> +++ b/mm/page_reporting.c
> @@ -370,7 +370,8 @@ int page_reporting_register(struct page_reporting_dev_info *prdev)
> */
>
> if (page_reporting_order == -1) {
> - if (prdev->order > 0 && prdev->order <= MAX_PAGE_ORDER)
> + if (prdev->order != PAGE_REPORTING_ORDER_UNSPECIFIED &&
> + prdev->order <= MAX_PAGE_ORDER)
Nit:
if (prdev->order != PAGE_REPORTING_ORDER_UNSPECIFIED &&
prdev->order <= MAX_PAGE_ORDER)
^ aligned here
Acked-by: David Hildenbrand (Arm) <david@kernel.org>
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH v4 5/5] mm/page_reporting: change page_reporting_order to PAGE_REPORTING_ORDER_UNSPECIFIED
From: David Hildenbrand (Arm) @ 2026-03-03 14:59 UTC (permalink / raw)
To: Yuvraj Sakshith, mst
Cc: kys, haiyangz, wei.liu, decui, longli, jasowang, xuanzhuo,
eperezma, akpm, lorenzo.stoakes, Liam.Howlett, vbabka, rppt,
surenb, mhocko, jackmanb, hannes, ziy, linux-hyperv, linux-kernel,
virtualization, linux-mm
In-Reply-To: <20260303113032.3008371-6-yuvraj.sakshith@oss.qualcomm.com>
On 3/3/26 12:30, Yuvraj Sakshith wrote:
> page_reporting_order when uninitialised, holds a magic number -1.
>
> Since we now maintain PAGE_REPORTING_ORDER_UNSPECIFIED as -1, which
> is also a flag, set page_reporting_order to this flag.
It's not really a flag. It's a handle for a magic value :)
>
> Signed-off-by: Yuvraj Sakshith <yuvraj.sakshith@oss.qualcomm.com>
> ---
> mm/page_reporting.c | 4 ++--
Thanks!
Acked-by: David Hildenbrand (Arm) <david@kernel.org>
--
Cheers,
David
^ permalink raw reply
* RE: [PATCH v4 0/5] Allow order zero pages in page reporting
From: Michael Kelley @ 2026-03-03 16:57 UTC (permalink / raw)
To: Yuvraj Sakshith, mst@redhat.com, david@kernel.org
Cc: kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org,
decui@microsoft.com, longli@microsoft.com, jasowang@redhat.com,
xuanzhuo@linux.alibaba.com, eperezma@redhat.com,
akpm@linux-foundation.org, lorenzo.stoakes@oracle.com,
Liam.Howlett@oracle.com, vbabka@suse.cz, rppt@kernel.org,
surenb@google.com, mhocko@suse.com, jackmanb@google.com,
hannes@cmpxchg.org, ziy@nvidia.com, linux-hyperv@vger.kernel.org,
linux-kernel@vger.kernel.org, virtualization@lists.linux.dev,
linux-mm@kvack.org
In-Reply-To: <20260303113032.3008371-1-yuvraj.sakshith@oss.qualcomm.com>
From: Yuvraj Sakshith <yuvraj.sakshith@oss.qualcomm.com> Sent: Tuesday, March 3, 2026 3:30 AM
>
> Today, page reporting sets page_reporting_order in two ways:
>
> (1) page_reporting.page_reporting_order cmdline parameter
> (2) Driver can pass order while registering itself.
>
> In both cases, order zero is ignored by free page reporting
> because it is used to set page_reporting_order to a default
> value, like MAX_PAGE_ORDER.
>
> In some cases we might want page_reporting_order to be zero.
>
> For instance, when virtio-balloon runs inside a guest with
> tiny memory (say, 16MB), it might not be able to find a order 1 page
> (or in the worst case order MAX_PAGE_ORDER page) after some uptime.
> Page reporting should be able to return order zero pages back for
> optimal memory relinquishment.
>
> This patch changes the default fallback value from '0' to '-1' in
> all possible clients of free page reporting (hv_balloon and
> virtio-balloon) together with allowing '0' as a valid order in
> page_reporting_register().
>
> Changes in v1:
> - Introduce PAGE_REPORTING_DEFAULT_ORDER macro (initially set to 0).
> - Make use of new macro in drivers (hv_balloon and virtio-balloon)
> working with page reporting.
> - Change PAGE_REPORTING_DEFAULT_ORDER to -1 as zero is a valid
> page order that can be requested.
>
> Changes in v2:
> - Better naming. Replace PAGE_REPORTING_DEFAULT_ORDER with
> PAGE_REPORTING_ORDER_UNSPECIFIED. This takes care of
> the situation where page reporting order is not specified
> in the commandline.
> - Minor commit message changes.
>
> Changes in v3:
> - Setting page_reporting_order's initial value to
> PAGE_REPORTING_ORDER_UNSPECIFIED moved to
> PATCH #5.
>
> Changes in v4:
> - Move PAGE_REPORTING_ORDER_UNSPECIFIED's usage with
> page_reporting_order to patch #5.
>
> Yuvraj Sakshith (5):
> mm/page_reporting: add PAGE_REPORTING_ORDER_UNSPECIFIED
> virtio_balloon: set unspecified page reporting order
> hv_balloon: set unspecified page reporting order
> mm/page_reporting: change PAGE_REPORTING_ORDER_UNSPECIFIED to -1
> mm/page_reporting: change page_reporting_order to
> PAGE_REPORTING_ORDER_UNSPECIFIED
>
> drivers/hv/hv_balloon.c | 2 +-
> drivers/virtio/virtio_balloon.c | 2 ++
> include/linux/page_reporting.h | 1 +
> mm/page_reporting.c | 7 ++++---
> 4 files changed, 8 insertions(+), 4 deletions(-)
>
> --
> 2.34.1
>
For the entire series,
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
^ permalink raw reply
* Re: [PATCH v4 0/5] Allow order zero pages in page reporting
From: Michael S. Tsirkin @ 2026-03-03 17:42 UTC (permalink / raw)
To: Yuvraj Sakshith
Cc: david, kys, haiyangz, wei.liu, decui, longli, jasowang, xuanzhuo,
eperezma, akpm, lorenzo.stoakes, Liam.Howlett, vbabka, rppt,
surenb, mhocko, jackmanb, hannes, ziy, linux-hyperv, linux-kernel,
virtualization, linux-mm
In-Reply-To: <20260303113032.3008371-1-yuvraj.sakshith@oss.qualcomm.com>
On Tue, Mar 03, 2026 at 03:30:27AM -0800, Yuvraj Sakshith wrote:
> Today, page reporting sets page_reporting_order in two ways:
>
> (1) page_reporting.page_reporting_order cmdline parameter
> (2) Driver can pass order while registering itself.
>
> In both cases, order zero is ignored by free page reporting
> because it is used to set page_reporting_order to a default
> value, like MAX_PAGE_ORDER.
>
> In some cases we might want page_reporting_order to be zero.
>
> For instance, when virtio-balloon runs inside a guest with
> tiny memory (say, 16MB), it might not be able to find a order 1 page
> (or in the worst case order MAX_PAGE_ORDER page) after some uptime.
> Page reporting should be able to return order zero pages back for
> optimal memory relinquishment.
>
> This patch changes the default fallback value from '0' to '-1' in
> all possible clients of free page reporting (hv_balloon and
> virtio-balloon) together with allowing '0' as a valid order in
> page_reporting_register().
virtio change is a technicality, so
Acked-by: Michael S. Tsirkin <mst@redhat.com>
> Changes in v1:
> - Introduce PAGE_REPORTING_DEFAULT_ORDER macro (initially set to 0).
> - Make use of new macro in drivers (hv_balloon and virtio-balloon)
> working with page reporting.
> - Change PAGE_REPORTING_DEFAULT_ORDER to -1 as zero is a valid
> page order that can be requested.
>
> Changes in v2:
> - Better naming. Replace PAGE_REPORTING_DEFAULT_ORDER with
> PAGE_REPORTING_ORDER_UNSPECIFIED. This takes care of
> the situation where page reporting order is not specified
> in the commandline.
> - Minor commit message changes.
>
> Changes in v3:
> - Setting page_reporting_order's initial value to
> PAGE_REPORTING_ORDER_UNSPECIFIED moved to
> PATCH #5.
>
> Changes in v4:
> - Move PAGE_REPORTING_ORDER_UNSPECIFIED's usage with
> page_reporting_order to patch #5.
>
> Yuvraj Sakshith (5):
> mm/page_reporting: add PAGE_REPORTING_ORDER_UNSPECIFIED
> virtio_balloon: set unspecified page reporting order
> hv_balloon: set unspecified page reporting order
> mm/page_reporting: change PAGE_REPORTING_ORDER_UNSPECIFIED to -1
> mm/page_reporting: change page_reporting_order to
> PAGE_REPORTING_ORDER_UNSPECIFIED
>
> drivers/hv/hv_balloon.c | 2 +-
> drivers/virtio/virtio_balloon.c | 2 ++
> include/linux/page_reporting.h | 1 +
> mm/page_reporting.c | 7 ++++---
> 4 files changed, 8 insertions(+), 4 deletions(-)
>
> --
> 2.34.1
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox