* [PATCH v2 2/4] hv_utils: Support host-initiated restart request
From: Dexuan Cui @ 2020-01-13 6:30 UTC (permalink / raw)
To: KY Srinivasan, Haiyang Zhang, Stephen Hemminger,
sashal@kernel.org, Sasha Levin, linux-hyperv@vger.kernel.org,
Michael Kelley, vkuznets, linux-kernel@vger.kernel.org
To test the code, run this command on the host:
Restart-VM $vm -Type Reboot
Signed-off-by: Dexuan Cui <decui@microsoft.com>
---
drivers/hv/hv_util.c | 23 ++++++++++++++++++++++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/hv/hv_util.c b/drivers/hv/hv_util.c
index 766bd8457346..fe3a316380c2 100644
--- a/drivers/hv/hv_util.c
+++ b/drivers/hv/hv_util.c
@@ -24,6 +24,8 @@
#define SD_MAJOR 3
#define SD_MINOR 0
+#define SD_MINOR_1 1
+#define SD_VERSION_3_1 (SD_MAJOR << 16 | SD_MINOR_1)
#define SD_VERSION (SD_MAJOR << 16 | SD_MINOR)
#define SD_MAJOR_1 1
@@ -50,8 +52,9 @@ static int sd_srv_version;
static int ts_srv_version;
static int hb_srv_version;
-#define SD_VER_COUNT 2
+#define SD_VER_COUNT 3
static const int sd_versions[] = {
+ SD_VERSION_3_1,
SD_VERSION,
SD_VERSION_1
};
@@ -118,11 +121,21 @@ static void perform_shutdown(struct work_struct *dummy)
orderly_poweroff(true);
}
+static void perform_restart(struct work_struct *dummy)
+{
+ orderly_reboot();
+}
+
/*
* Perform the shutdown operation in a thread context.
*/
static DECLARE_WORK(shutdown_work, perform_shutdown);
+/*
+ * Perform the restart operation in a thread context.
+ */
+static DECLARE_WORK(restart_work, perform_restart);
+
static void shutdown_onchannelcallback(void *context)
{
struct vmbus_channel *channel = context;
@@ -166,6 +179,14 @@ static void shutdown_onchannelcallback(void *context)
pr_info("Shutdown request received -"
" graceful shutdown initiated\n");
break;
+ case 2:
+ case 3:
+ pr_info("Restart request received -"
+ " graceful restart initiated\n");
+ icmsghdrp->status = HV_S_OK;
+
+ schedule_work(&restart_work);
+ break;
default:
icmsghdrp->status = HV_E_FAIL;
execute_shutdown = false;
--
2.19.1
^ permalink raw reply related
* [PATCH v2 3/4] hv_utils: Support host-initiated hibernation request
From: Dexuan Cui @ 2020-01-13 6:31 UTC (permalink / raw)
To: KY Srinivasan, Haiyang Zhang, Stephen Hemminger,
sashal@kernel.org, Sasha Levin, linux-hyperv@vger.kernel.org,
Michael Kelley, vkuznets, linux-kernel@vger.kernel.org
Update the Shutdown IC version to 3.2, which is required for the host to
send the hibernation request.
The user is expected to create the below udev rule file, which is applied
upon the host-initiated hibernation request:
root@localhost:~# cat /usr/lib/udev/rules.d/40-vm-hibernation.rules
SUBSYSTEM=="vmbus", ACTION=="change", DRIVER=="hv_utils", ENV{EVENT}=="hibernate", RUN+="/usr/bin/systemctl hibernate"
Signed-off-by: Dexuan Cui <decui@microsoft.com>
---
drivers/hv/hv_util.c | 52 +++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 51 insertions(+), 1 deletion(-)
diff --git a/drivers/hv/hv_util.c b/drivers/hv/hv_util.c
index fe3a316380c2..d5216af62788 100644
--- a/drivers/hv/hv_util.c
+++ b/drivers/hv/hv_util.c
@@ -25,7 +25,9 @@
#define SD_MAJOR 3
#define SD_MINOR 0
#define SD_MINOR_1 1
+#define SD_MINOR_2 2
#define SD_VERSION_3_1 (SD_MAJOR << 16 | SD_MINOR_1)
+#define SD_VERSION_3_2 (SD_MAJOR << 16 | SD_MINOR_2)
#define SD_VERSION (SD_MAJOR << 16 | SD_MINOR)
#define SD_MAJOR_1 1
@@ -52,9 +54,10 @@ static int sd_srv_version;
static int ts_srv_version;
static int hb_srv_version;
-#define SD_VER_COUNT 3
+#define SD_VER_COUNT 4
static const int sd_versions[] = {
SD_VERSION_3_1,
+ SD_VERSION_3_2,
SD_VERSION,
SD_VERSION_1
};
@@ -78,9 +81,45 @@ static const int fw_versions[] = {
UTIL_WS2K8_FW_VERSION
};
+/*
+ * Send the "hibernate" udev event in a thread context.
+ */
+struct hibernate_work_context {
+ struct work_struct work;
+ struct hv_device *dev;
+};
+
+static struct hibernate_work_context hibernate_context;
+static bool execute_hibernate;
+
+static void send_hibernate_uevent(struct work_struct *work)
+{
+ char *uevent_env[2] = { "EVENT=hibernate", NULL };
+ struct hibernate_work_context *ctx;
+
+ ctx = container_of(work, struct hibernate_work_context, work);
+
+ kobject_uevent_env(&ctx->dev->device.kobj, KOBJ_CHANGE, uevent_env);
+
+ pr_info("Sent hibernation uevent\n");
+}
+
+static int hv_shutdown_init(struct hv_util_service *srv)
+{
+ struct vmbus_channel *channel = srv->channel;
+
+ INIT_WORK(&hibernate_context.work, send_hibernate_uevent);
+ hibernate_context.dev = channel->device_obj;
+
+ execute_hibernate = hv_is_hibernation_supported();
+
+ return 0;
+}
+
static void shutdown_onchannelcallback(void *context);
static struct hv_util_service util_shutdown = {
.util_cb = shutdown_onchannelcallback,
+ .util_init = hv_shutdown_init,
};
static int hv_timesync_init(struct hv_util_service *srv);
@@ -187,6 +226,17 @@ static void shutdown_onchannelcallback(void *context)
schedule_work(&restart_work);
break;
+ case 4:
+ case 5:
+ pr_info("Hibernation request received\n");
+
+ if (execute_hibernate) {
+ icmsghdrp->status = HV_S_OK;
+ schedule_work(&hibernate_context.work);
+ } else {
+ icmsghdrp->status = HV_E_FAIL;
+ }
+ break;
default:
icmsghdrp->status = HV_E_FAIL;
execute_shutdown = false;
--
2.19.1
^ permalink raw reply related
* [PATCH v2 4/4] hv_utils: Add the support of hibernation
From: Dexuan Cui @ 2020-01-13 6:32 UTC (permalink / raw)
To: KY Srinivasan, Haiyang Zhang, Stephen Hemminger,
sashal@kernel.org, Sasha Levin, linux-hyperv@vger.kernel.org,
Michael Kelley, vkuznets, linux-kernel@vger.kernel.org
Add util_pre_suspend() and util_pre_resume() for some hv_utils devices
(e.g. kvp/vss/fcopy), because they need special handling before
util_suspend() calls vmbus_close().
For kvp, all the possible pending work items should be cancelled.
For vss and fcopy, extra clean-up needs to be done, i.e. fake a THAW
message for hv_vss_daemon and fake a CANCEL_FCOPY message for
hv_fcopy_daemonemon, otherwise when the VM resums back, the daemons
can end up in an inconsistent state (i.e. the file systems are
frozen but will never be thawed; the file transmitted via fcopy
may not be complete). Note: there is an extra patch for the daemons:
"Tools: hv: Reopen the devices if read() or write() returns errors",
because the hv_utils driver can not guarantee the whole transaction
finishes completely once util_suspend() starts to run (at this time,
all the userspace processes are frozen).
util_probe() disables channel->callback_event to avoid the race with
the the channel callback.
Signed-off-by: Dexuan Cui <decui@microsoft.com>
---
drivers/hv/hv_fcopy.c | 58 ++++++++++++++++++++++++++++++++++++-
drivers/hv/hv_kvp.c | 44 ++++++++++++++++++++++++++--
drivers/hv/hv_snapshot.c | 60 +++++++++++++++++++++++++++++++++++++--
drivers/hv/hv_util.c | 60 ++++++++++++++++++++++++++++++++++++++-
drivers/hv/hyperv_vmbus.h | 6 ++++
include/linux/hyperv.h | 2 ++
6 files changed, 224 insertions(+), 6 deletions(-)
diff --git a/drivers/hv/hv_fcopy.c b/drivers/hv/hv_fcopy.c
index 08fa4a5de644..d63853f16356 100644
--- a/drivers/hv/hv_fcopy.c
+++ b/drivers/hv/hv_fcopy.c
@@ -346,9 +346,65 @@ int hv_fcopy_init(struct hv_util_service *srv)
return 0;
}
+static void hv_fcopy_cancel_work(void)
+{
+ cancel_delayed_work_sync(&fcopy_timeout_work);
+ cancel_work_sync(&fcopy_send_work);
+}
+
+int hv_fcopy_pre_suspend(void)
+{
+ struct vmbus_channel *channel = fcopy_transaction.recv_channel;
+ struct hv_fcopy_hdr *fcopy_msg;
+
+ tasklet_disable(&channel->callback_event);
+
+ /*
+ * Fake a CANCEL_FCOPY message to the user space daemon in case the
+ * daemon is in the middle of copying some file. It doesn't matter if
+ * there is already a message pending to be delivered to the user
+ * space: we force fcopy_transaction.state to be HVUTIL_READY, so the
+ * user space daemon's write() will fail with -EINVAL (see
+ * fcopy_on_msg()), and the daemon will reset the device by closing and
+ * re-opening it.
+ */
+ fcopy_msg = kzalloc(sizeof(*fcopy_msg), GFP_KERNEL);
+ if (!fcopy_msg)
+ goto err;
+
+ fcopy_msg->operation = CANCEL_FCOPY;
+
+ hv_fcopy_cancel_work();
+
+ /* We don't care about the return value. */
+ hvutil_transport_send(hvt, fcopy_msg, sizeof(*fcopy_msg), NULL);
+
+ kfree(fcopy_msg);
+
+ fcopy_transaction.state = HVUTIL_READY;
+
+ /* tasklet_enable() will be called in hv_fcopy_pre_resume(). */
+
+ return 0;
+err:
+ tasklet_enable(&channel->callback_event);
+ return -ENOMEM;
+}
+
+int hv_fcopy_pre_resume(void)
+{
+ struct vmbus_channel *channel = fcopy_transaction.recv_channel;
+
+ tasklet_enable(&channel->callback_event);
+
+ return 0;
+}
+
void hv_fcopy_deinit(void)
{
fcopy_transaction.state = HVUTIL_DEVICE_DYING;
- cancel_delayed_work_sync(&fcopy_timeout_work);
+
+ hv_fcopy_cancel_work();
+
hvutil_transport_destroy(hvt);
}
diff --git a/drivers/hv/hv_kvp.c b/drivers/hv/hv_kvp.c
index ae7c028dc5a8..ca03f68df5d0 100644
--- a/drivers/hv/hv_kvp.c
+++ b/drivers/hv/hv_kvp.c
@@ -758,11 +758,51 @@ hv_kvp_init(struct hv_util_service *srv)
return 0;
}
-void hv_kvp_deinit(void)
+static void hv_kvp_cancel_work(void)
{
- kvp_transaction.state = HVUTIL_DEVICE_DYING;
cancel_delayed_work_sync(&kvp_host_handshake_work);
cancel_delayed_work_sync(&kvp_timeout_work);
cancel_work_sync(&kvp_sendkey_work);
+}
+
+int hv_kvp_pre_suspend(void)
+{
+ struct vmbus_channel *channel = kvp_transaction.recv_channel;
+
+ tasklet_disable(&channel->callback_event);
+
+ /*
+ * If there is a pending transtion, it's unnecessary to tell the host
+ * that the tranction will fail, becasue that is implied when
+ * util_suspend() calls vmbus_close() later.
+ */
+ hv_kvp_cancel_work();
+
+ /*
+ * Forece the state to READY to handle the ICMSGTYPE_NEGOTIATE message
+ * later. The user space daemon may go out of order and its write()
+ * may get an EINVAL error: this doesn't matter since the daemon will
+ * reset the device by closing and re-opening the device.
+ */
+ kvp_transaction.state = HVUTIL_READY;
+
+ return 0;
+}
+
+int hv_kvp_pre_resume(void)
+{
+ struct vmbus_channel *channel = kvp_transaction.recv_channel;
+
+ tasklet_enable(&channel->callback_event);
+
+ return 0;
+}
+
+void hv_kvp_deinit(void)
+{
+ kvp_transaction.state = HVUTIL_DEVICE_DYING;
+
+ hv_kvp_cancel_work();
+
hvutil_transport_destroy(hvt);
}
diff --git a/drivers/hv/hv_snapshot.c b/drivers/hv/hv_snapshot.c
index 03b6454268b3..eb766ff8841b 100644
--- a/drivers/hv/hv_snapshot.c
+++ b/drivers/hv/hv_snapshot.c
@@ -229,6 +229,7 @@ static void vss_handle_request(struct work_struct *dummy)
vss_transaction.state = HVUTIL_HOSTMSG_RECEIVED;
vss_send_op();
return;
+
case VSS_OP_GET_DM_INFO:
vss_transaction.msg->dm_info.flags = 0;
break;
@@ -379,10 +380,65 @@ hv_vss_init(struct hv_util_service *srv)
return 0;
}
-void hv_vss_deinit(void)
+static void hv_vss_cancel_work(void)
{
- vss_transaction.state = HVUTIL_DEVICE_DYING;
cancel_delayed_work_sync(&vss_timeout_work);
cancel_work_sync(&vss_handle_request_work);
+}
+
+int hv_vss_pre_suspend(void)
+{
+ struct vmbus_channel *channel = vss_transaction.recv_channel;
+ struct hv_vss_msg *vss_msg;
+
+ tasklet_disable(&channel->callback_event);
+
+ /*
+ * Fake a THAW message for the user space daemon in case the daemon
+ * has frozen the file systems. It doesn't matter if there is already
+ * a message pending to be delivered to the user space: we force
+ * vss_transaction.state to be HVUTIL_READY, so the user space daemon's
+ * write() will fail with -EINVAL (see vss_on_msg()), and the daemon
+ * will reset the device by closing and re-opening it.
+ */
+ vss_msg = kzalloc(sizeof(*vss_msg), GFP_KERNEL);
+ if (!vss_msg)
+ goto err;
+
+ vss_msg->vss_hdr.operation = VSS_OP_THAW;
+
+ /* Cancel any possible pending work. */
+ hv_vss_cancel_work();
+
+ /* We don't care about the return value. */
+ hvutil_transport_send(hvt, vss_msg, sizeof(*vss_msg), NULL);
+
+ kfree(vss_msg);
+
+ vss_transaction.state = HVUTIL_READY;
+
+ /* tasklet_enable() will be called in hv_vss_pre_resume(). */
+
+ return 0;
+err:
+ tasklet_enable(&channel->callback_event);
+ return -ENOMEM;
+}
+
+int hv_vss_pre_resume(void)
+{
+ struct vmbus_channel *channel = vss_transaction.recv_channel;
+
+ tasklet_enable(&channel->callback_event);
+
+ return 0;
+}
+
+void hv_vss_deinit(void)
+{
+ vss_transaction.state = HVUTIL_DEVICE_DYING;
+
+ hv_vss_cancel_work();
+
hvutil_transport_destroy(hvt);
}
diff --git a/drivers/hv/hv_util.c b/drivers/hv/hv_util.c
index d5216af62788..255faa3d657c 100644
--- a/drivers/hv/hv_util.c
+++ b/drivers/hv/hv_util.c
@@ -123,12 +123,14 @@ static struct hv_util_service util_shutdown = {
};
static int hv_timesync_init(struct hv_util_service *srv);
+static int hv_timesync_pre_suspend(void);
static void hv_timesync_deinit(void);
static void timesync_onchannelcallback(void *context);
static struct hv_util_service util_timesynch = {
.util_cb = timesync_onchannelcallback,
.util_init = hv_timesync_init,
+ .util_pre_suspend = hv_timesync_pre_suspend,
.util_deinit = hv_timesync_deinit,
};
@@ -140,18 +142,24 @@ static struct hv_util_service util_heartbeat = {
static struct hv_util_service util_kvp = {
.util_cb = hv_kvp_onchannelcallback,
.util_init = hv_kvp_init,
+ .util_pre_suspend = hv_kvp_pre_suspend,
+ .util_pre_resume = hv_kvp_pre_resume,
.util_deinit = hv_kvp_deinit,
};
static struct hv_util_service util_vss = {
.util_cb = hv_vss_onchannelcallback,
.util_init = hv_vss_init,
+ .util_pre_suspend = hv_vss_pre_suspend,
+ .util_pre_resume = hv_vss_pre_resume,
.util_deinit = hv_vss_deinit,
};
static struct hv_util_service util_fcopy = {
.util_cb = hv_fcopy_onchannelcallback,
.util_init = hv_fcopy_init,
+ .util_pre_suspend = hv_fcopy_pre_suspend,
+ .util_pre_resume = hv_fcopy_pre_resume,
.util_deinit = hv_fcopy_deinit,
};
@@ -512,6 +520,41 @@ static int util_remove(struct hv_device *dev)
return 0;
}
+static int util_suspend(struct hv_device *dev)
+{
+ struct hv_util_service *srv = hv_get_drvdata(dev);
+ int ret = 0;
+
+ if (srv->util_pre_suspend) {
+ ret = srv->util_pre_suspend();
+
+ if (ret)
+ return ret;
+ }
+
+ vmbus_close(dev->channel);
+
+ return 0;
+}
+
+static int util_resume(struct hv_device *dev)
+{
+ struct hv_util_service *srv = hv_get_drvdata(dev);
+ int ret = 0;
+
+ if (srv->util_pre_resume) {
+ ret = srv->util_pre_resume();
+
+ if (ret)
+ return ret;
+ }
+
+ ret = vmbus_open(dev->channel, 4 * HV_HYP_PAGE_SIZE,
+ 4 * HV_HYP_PAGE_SIZE, NULL, 0, srv->util_cb,
+ dev->channel);
+ return ret;
+}
+
static const struct hv_vmbus_device_id id_table[] = {
/* Shutdown guid */
{ HV_SHUTDOWN_GUID,
@@ -548,6 +591,8 @@ static struct hv_driver util_drv = {
.id_table = id_table,
.probe = util_probe,
.remove = util_remove,
+ .suspend = util_suspend,
+ .resume = util_resume,
.driver = {
.probe_type = PROBE_PREFER_ASYNCHRONOUS,
},
@@ -617,11 +662,24 @@ static int hv_timesync_init(struct hv_util_service *srv)
return 0;
}
+static void hv_timesync_cancel_work(void)
+{
+ cancel_work_sync(&adj_time_work);
+}
+
+static int hv_timesync_pre_suspend(void)
+{
+ hv_timesync_cancel_work();
+
+ return 0;
+}
+
static void hv_timesync_deinit(void)
{
if (hv_ptp_clock)
ptp_clock_unregister(hv_ptp_clock);
- cancel_work_sync(&adj_time_work);
+
+ hv_timesync_cancel_work();
}
static int __init init_hyperv_utils(void)
diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
index 20edcfd3b96c..f5fa3b3c9baf 100644
--- a/drivers/hv/hyperv_vmbus.h
+++ b/drivers/hv/hyperv_vmbus.h
@@ -352,14 +352,20 @@ void vmbus_on_msg_dpc(unsigned long data);
int hv_kvp_init(struct hv_util_service *srv);
void hv_kvp_deinit(void);
+int hv_kvp_pre_suspend(void);
+int hv_kvp_pre_resume(void);
void hv_kvp_onchannelcallback(void *context);
int hv_vss_init(struct hv_util_service *srv);
void hv_vss_deinit(void);
+int hv_vss_pre_suspend(void);
+int hv_vss_pre_resume(void);
void hv_vss_onchannelcallback(void *context);
int hv_fcopy_init(struct hv_util_service *srv);
void hv_fcopy_deinit(void);
+int hv_fcopy_pre_suspend(void);
+int hv_fcopy_pre_resume(void);
void hv_fcopy_onchannelcallback(void *context);
void vmbus_initiate_unload(bool crash);
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index 41c58011431e..692c89ccf5df 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -1435,6 +1435,8 @@ struct hv_util_service {
void (*util_cb)(void *);
int (*util_init)(struct hv_util_service *);
void (*util_deinit)(void);
+ int (*util_pre_suspend)(void);
+ int (*util_pre_resume)(void);
};
struct vmbuspipe_hdr {
--
2.19.1
^ permalink raw reply related
* RE: [PATCH] x86/hyper-v: remove unnecessary conversions to bool
From: Vitaly Kuznetsov @ 2020-01-13 8:07 UTC (permalink / raw)
To: Michael Kelley, Chen Zhou
Cc: linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org,
chenzhou10@huawei.com, tglx@linutronix.de, mingo@redhat.com
In-Reply-To: <MW2PR2101MB1052B01B542F0C0A576928CBD73A0@MW2PR2101MB1052.namprd21.prod.outlook.com>
Michael Kelley <mikelley@microsoft.com> writes:
> From: Vitaly Kuznetsov <vkuznets@redhat.com> Sent: Friday, January 10, 2020 4:00 AM
>>
>>
>> I'd suggest we get rid of bool functions completely instead, something
>> like (untested):
>
> Just curious: Why prefer returning a u16 instead of a bool? To avoid
> having to test 'ret' for zero in the return statements, or is there some
> broader reason?
Basically to preserve hypercall failure code and not hide it under 'false'.
>> - ipi_arg.cpu_mask);
>> - return ((ret == 0) ? true : false);
>> + return (u16)hv_do_fast_hypercall16(HVCALL_SEND_IPI, ipi_arg.vector,
>> + ipi_arg.cpu_mask);
>
> The cast to u16 seems a bit dangerous. The hypercall status code is indeed
> returned in the low 16 bits of the hypercall result value, so it works, and
> maybe that is why you suggested u16 as the function return value. But it
> is a non-obvious assumption.
This is not obvious, I agree, and we can create a wrapper for it but we
more or less must convert it to 'u16': uppper bits don't indicate a
failure (e.g. 'reps complete').
--
Vitaly
^ permalink raw reply
* RE: [EXTERNAL] Re: [RFC PATCH V2 2/10] mm: expose is_mem_section_removable() symbol
From: Tianyu Lan @ 2020-01-13 14:49 UTC (permalink / raw)
To: David Hildenbrand, Michal Hocko, lantianyu1986@gmail.com
Cc: KY Srinivasan, Haiyang Zhang, Stephen Hemminger,
sashal@kernel.org, akpm@linux-foundation.org, Michael Kelley,
linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, vkuznets, eric.devolder@oracle.com,
vbabka@suse.cz, osalvador@suse.de, Pasha Tatashin,
rppt@linux.ibm.com
In-Reply-To: <99a6db0c-6d73-d982-58b3-7a0172748ae4@redhat.com>
> From: David Hildenbrand <david@redhat.com>
> Sent: Friday, January 10, 2020 9:42 PM
> To: Michal Hocko <mhocko@kernel.org>; lantianyu1986@gmail.com
> Cc: KY Srinivasan <kys@microsoft.com>; Haiyang Zhang
> <haiyangz@microsoft.com>; Stephen Hemminger <sthemmin@microsoft.com>;
> sashal@kernel.org; akpm@linux-foundation.org; Michael Kelley
> <mikelley@microsoft.com>; Tianyu Lan <Tianyu.Lan@microsoft.com>; linux-
> hyperv@vger.kernel.org; linux-kernel@vger.kernel.org; linux-mm@kvack.org;
> vkuznets <vkuznets@redhat.com>; eric.devolder@oracle.com; vbabka@suse.cz;
> osalvador@suse.de; Pasha Tatashin <Pavel.Tatashin@microsoft.com>;
> rppt@linux.ibm.com
> Subject: [EXTERNAL] Re: [RFC PATCH V2 2/10] mm: expose
> is_mem_section_removable() symbol
>
> On 07.01.20 14:36, Michal Hocko wrote:
> > On Tue 07-01-20 21:09:42, lantianyu1986@gmail.com wrote:
> >> From: Tianyu Lan <Tianyu.Lan@microsoft.com>
> >>
> >> Hyper-V balloon driver will use is_mem_section_removable() to check
> >> whether memory block is removable or not when receive memory hot
> >> remove msg. Expose it.
> >
> > I do not think this is a good idea. The check is inherently racy. Why
> > cannot the balloon driver simply hotremove the region when asked?
> >
>
> It's not only racy, it also gives no guarantees. False postives and false negatives
> are possible.
>
> If you want to avoid having to loop forever trying to offline when calling
> offline_and_remove_memory(), you could try to
> alloc_contig_range() the memory first and then play the PG_offline+notifier
> game like virtio-mem.
>
> I don't remember clearly, but I think pinned pages can make offlining loop for a
> long time. And I remember there were other scenarios as well (including out of
> memory conditions and similar).
>
> I sent an RFC [1] for powerpc/memtrace that does the same (just error
> handling is more complicated as it wants to offline and remove multiple
> consecutive memory blocks) - if you want to try to go down that path.
>
Hi David & Michal:
Thanks for your review. Some memory blocks are not suitable for hot-plug.
If not check memory block's removable, offline_pages() will report some failure error
e.g, "failed due to memory holes" and "failure to isolate range". I think the check maybe
added into offline_and_remove_memory()? This may help to not create/expose a new
interface to do such check in module.
^ permalink raw reply
* Re: [EXTERNAL] Re: [RFC PATCH V2 2/10] mm: expose is_mem_section_removable() symbol
From: David Hildenbrand @ 2020-01-13 15:01 UTC (permalink / raw)
To: Tianyu Lan, Michal Hocko, lantianyu1986@gmail.com
Cc: KY Srinivasan, Haiyang Zhang, Stephen Hemminger,
sashal@kernel.org, akpm@linux-foundation.org, Michael Kelley,
linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, vkuznets, eric.devolder@oracle.com,
vbabka@suse.cz, osalvador@suse.de, Pasha Tatashin,
rppt@linux.ibm.com
In-Reply-To: <SG2P153MB0349F85FB0C1C02F55391F6D92350@SG2P153MB0349.APCP153.PROD.OUTLOOK.COM>
On 13.01.20 15:49, Tianyu Lan wrote:
>> From: David Hildenbrand <david@redhat.com>
>> Sent: Friday, January 10, 2020 9:42 PM
>> To: Michal Hocko <mhocko@kernel.org>; lantianyu1986@gmail.com
>> Cc: KY Srinivasan <kys@microsoft.com>; Haiyang Zhang
>> <haiyangz@microsoft.com>; Stephen Hemminger <sthemmin@microsoft.com>;
>> sashal@kernel.org; akpm@linux-foundation.org; Michael Kelley
>> <mikelley@microsoft.com>; Tianyu Lan <Tianyu.Lan@microsoft.com>; linux-
>> hyperv@vger.kernel.org; linux-kernel@vger.kernel.org; linux-mm@kvack.org;
>> vkuznets <vkuznets@redhat.com>; eric.devolder@oracle.com; vbabka@suse.cz;
>> osalvador@suse.de; Pasha Tatashin <Pavel.Tatashin@microsoft.com>;
>> rppt@linux.ibm.com
>> Subject: [EXTERNAL] Re: [RFC PATCH V2 2/10] mm: expose
>> is_mem_section_removable() symbol
>>
>> On 07.01.20 14:36, Michal Hocko wrote:
>>> On Tue 07-01-20 21:09:42, lantianyu1986@gmail.com wrote:
>>>> From: Tianyu Lan <Tianyu.Lan@microsoft.com>
>>>>
>>>> Hyper-V balloon driver will use is_mem_section_removable() to check
>>>> whether memory block is removable or not when receive memory hot
>>>> remove msg. Expose it.
>>>
>>> I do not think this is a good idea. The check is inherently racy. Why
>>> cannot the balloon driver simply hotremove the region when asked?
>>>
>>
>> It's not only racy, it also gives no guarantees. False postives and false negatives
>> are possible.
>>
>> If you want to avoid having to loop forever trying to offline when calling
>> offline_and_remove_memory(), you could try to
>> alloc_contig_range() the memory first and then play the PG_offline+notifier
>> game like virtio-mem.
>>
>> I don't remember clearly, but I think pinned pages can make offlining loop for a
>> long time. And I remember there were other scenarios as well (including out of
>> memory conditions and similar).
>>
>> I sent an RFC [1] for powerpc/memtrace that does the same (just error
>> handling is more complicated as it wants to offline and remove multiple
>> consecutive memory blocks) - if you want to try to go down that path.
>>
> Hi David & Michal:
> Thanks for your review. Some memory blocks are not suitable for hot-plug.
> If not check memory block's removable, offline_pages() will report some failure error
> e.g, "failed due to memory holes" and "failure to isolate range". I think the check maybe
> added into offline_and_remove_memory()? This may help to not create/expose a new
> interface to do such check in module.
So it's all about the logging output. Duplicating these checks feels
very wrong. And you will still get plenty of page dumps (read below), so
that won't help.
We have pr_debug() for these "failure ..." message. that should
therefore not be an issue on production systems, right?
However, you will see dump_page()s quite often, which logs via pr_warn().
Of course, we could add a mechanism to temporarily disable logging
output for these call paths, but it might actually be helpful for
debugging. We might just want to convert everything that is not actually
a warning to pr_debug() - especially in dump_page().
--
Thanks,
David / dhildenb
^ permalink raw reply
* [PATCH] hv_netvsc: Fix memory leak when removing rndis device
From: Mohammed Gamal @ 2020-01-13 19:27 UTC (permalink / raw)
To: linux-hyperv, sthemmin, haiyangz, netdev
Cc: kys, sashal, vkuznets, cavery, linux-kernel, Mohammed Gamal
kmemleak detects the following memory leak when hot removing
a network device:
unreferenced object 0xffff888083f63600 (size 256):
comm "kworker/0:1", pid 12, jiffies 4294831717 (age 1113.676s)
hex dump (first 32 bytes):
00 40 c7 33 80 88 ff ff 00 00 00 00 10 00 00 00 .@.3............
00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N..........
backtrace:
[<00000000d4a8f5be>] rndis_filter_device_add+0x117/0x11c0 [hv_netvsc]
[<000000009c02d75b>] netvsc_probe+0x5e7/0xbf0 [hv_netvsc]
[<00000000ddafce23>] vmbus_probe+0x74/0x170 [hv_vmbus]
[<00000000046e64f1>] really_probe+0x22f/0xb50
[<000000005cc35eb7>] driver_probe_device+0x25e/0x370
[<0000000043c642b2>] bus_for_each_drv+0x11f/0x1b0
[<000000005e3d09f0>] __device_attach+0x1c6/0x2f0
[<00000000a72c362f>] bus_probe_device+0x1a6/0x260
[<0000000008478399>] device_add+0x10a3/0x18e0
[<00000000cf07b48c>] vmbus_device_register+0xe7/0x1e0 [hv_vmbus]
[<00000000d46cf032>] vmbus_add_channel_work+0x8ab/0x1770 [hv_vmbus]
[<000000002c94bb64>] process_one_work+0x919/0x17d0
[<0000000096de6781>] worker_thread+0x87/0xb40
[<00000000fbe7397e>] kthread+0x333/0x3f0
[<000000004f844269>] ret_from_fork+0x3a/0x50
rndis_filter_device_add() allocates an instance of struct rndis_device
which never gets deallocated and rndis_filter_device_remove() sets
net_device->extension which points to the rndis_device struct to NULL
without ever freeing the structure first, leaving it dangling.
This patch fixes this by freeing the structure before setting
net_device->extension to NULL
Signed-off-by: Mohammed Gamal <mgamal@redhat.com>
---
drivers/net/hyperv/rndis_filter.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/hyperv/rndis_filter.c b/drivers/net/hyperv/rndis_filter.c
index 857c4bea451c..d2e094f521a4 100644
--- a/drivers/net/hyperv/rndis_filter.c
+++ b/drivers/net/hyperv/rndis_filter.c
@@ -1443,6 +1443,7 @@ void rndis_filter_device_remove(struct hv_device *dev,
/* Halt and release the rndis device */
rndis_filter_halt_device(net_dev, rndis_dev);
+ kfree(rndis_dev);
net_dev->extension = NULL;
netvsc_device_remove(dev);
--
2.21.0
^ permalink raw reply related
* RE: [Patch v3 1/2] PCI: hv: Decouple the func definition in hv_dr_state from VSP message
From: Long Li @ 2020-01-13 19:30 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: longli@linuxonhyperv.com, KY Srinivasan, Haiyang Zhang,
Stephen Hemminger, Sasha Levin, Lorenzo Pieralisi, Andrew Murray,
linux-hyperv@vger.kernel.org, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20200111175341.GA238104@google.com>
>Subject: Re: [Patch v3 1/2] PCI: hv: Decouple the func definition in hv_dr_state
>from VSP message
>
>On Sat, Jan 11, 2020 at 08:27:25AM +0000, Long Li wrote:
>> Hi Bjorn,
>>
>> I have addressed all the prior comments in this v3 patch. Please take a look.
>
>Lorenzo normally merges hv updates, so I'm sure this is on his list to take a look.
>I pointed out a few spelling and similar nits, but I didn't review the actual
>substance of v3.
>
>Bjorn
Thanks, I will address your comments and send v4.
Long
^ permalink raw reply
* RE: [PATCH] hv_netvsc: Fix memory leak when removing rndis device
From: Haiyang Zhang @ 2020-01-13 19:55 UTC (permalink / raw)
To: Mohammed Gamal, linux-hyperv@vger.kernel.org, Stephen Hemminger,
netdev@vger.kernel.org
Cc: KY Srinivasan, sashal@kernel.org, vkuznets, cavery,
linux-kernel@vger.kernel.org
In-Reply-To: <20200113192752.1266-1-mgamal@redhat.com>
> -----Original Message-----
> From: Mohammed Gamal <mgamal@redhat.com>
> Sent: Monday, January 13, 2020 2:28 PM
> To: linux-hyperv@vger.kernel.org; Stephen Hemminger
> <sthemmin@microsoft.com>; Haiyang Zhang <haiyangz@microsoft.com>;
> netdev@vger.kernel.org
> Cc: KY Srinivasan <kys@microsoft.com>; sashal@kernel.org; vkuznets
> <vkuznets@redhat.com>; cavery <cavery@redhat.com>; linux-
> kernel@vger.kernel.org; Mohammed Gamal <mgamal@redhat.com>
> Subject: [PATCH] hv_netvsc: Fix memory leak when removing rndis device
>
> kmemleak detects the following memory leak when hot removing a network
> device:
>
> unreferenced object 0xffff888083f63600 (size 256):
> comm "kworker/0:1", pid 12, jiffies 4294831717 (age 1113.676s)
> hex dump (first 32 bytes):
> 00 40 c7 33 80 88 ff ff 00 00 00 00 10 00 00 00 .@.3............
> 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N..........
> backtrace:
> [<00000000d4a8f5be>] rndis_filter_device_add+0x117/0x11c0 [hv_netvsc]
> [<000000009c02d75b>] netvsc_probe+0x5e7/0xbf0 [hv_netvsc]
> [<00000000ddafce23>] vmbus_probe+0x74/0x170 [hv_vmbus]
> [<00000000046e64f1>] really_probe+0x22f/0xb50
> [<000000005cc35eb7>] driver_probe_device+0x25e/0x370
> [<0000000043c642b2>] bus_for_each_drv+0x11f/0x1b0
> [<000000005e3d09f0>] __device_attach+0x1c6/0x2f0
> [<00000000a72c362f>] bus_probe_device+0x1a6/0x260
> [<0000000008478399>] device_add+0x10a3/0x18e0
> [<00000000cf07b48c>] vmbus_device_register+0xe7/0x1e0 [hv_vmbus]
> [<00000000d46cf032>] vmbus_add_channel_work+0x8ab/0x1770 [hv_vmbus]
> [<000000002c94bb64>] process_one_work+0x919/0x17d0
> [<0000000096de6781>] worker_thread+0x87/0xb40
> [<00000000fbe7397e>] kthread+0x333/0x3f0
> [<000000004f844269>] ret_from_fork+0x3a/0x50
>
> rndis_filter_device_add() allocates an instance of struct rndis_device which
> never gets deallocated and rndis_filter_device_remove() sets net_device-
> >extension which points to the rndis_device struct to NULL without ever freeing
> the structure first, leaving it dangling.
>
> This patch fixes this by freeing the structure before setting net_device-
> >extension to NULL
>
> Signed-off-by: Mohammed Gamal <mgamal@redhat.com>
> ---
> drivers/net/hyperv/rndis_filter.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/hyperv/rndis_filter.c b/drivers/net/hyperv/rndis_filter.c
> index 857c4bea451c..d2e094f521a4 100644
> --- a/drivers/net/hyperv/rndis_filter.c
> +++ b/drivers/net/hyperv/rndis_filter.c
> @@ -1443,6 +1443,7 @@ void rndis_filter_device_remove(struct hv_device
> *dev,
> /* Halt and release the rndis device */
> rndis_filter_halt_device(net_dev, rndis_dev);
>
> + kfree(rndis_dev);
> net_dev->extension = NULL;
The struct rndis_device *should* be freed in free_netvsc_device_rcu()
==> free_netvsc_device():
static void free_netvsc_device(struct rcu_head *head)
{
struct netvsc_device *nvdev
= container_of(head, struct netvsc_device, rcu);
int i;
kfree(nvdev->extension);
So we no longer free it in the rndis_filter_device_remove().
But, the commit 02400fcee2542ee334a2394e0d9f6efd969fe782 did
have a bug:
Date: Tue, 20 Mar 2018 15:03:03 -0700
[PATCH] hv_netvsc: use RCU to fix concurrent rx and queue changes
It should have removed the following line when moving the free() to
free_netvsc_device():
> net_dev->extension = NULL;
Then, the leak of rndis_dev will be fixed. I suggested you to fix it in this
way.
Thanks,
- Haiyang
^ permalink raw reply
* Re: [PATCH] hv_netvsc: Fix memory leak when removing rndis device
From: Stephen Hemminger @ 2020-01-13 20:02 UTC (permalink / raw)
To: Mohammed Gamal
Cc: linux-hyperv, sthemmin, haiyangz, netdev, kys, sashal, vkuznets,
cavery, linux-kernel
In-Reply-To: <20200113192752.1266-1-mgamal@redhat.com>
On Mon, 13 Jan 2020 21:27:52 +0200
Mohammed Gamal <mgamal@redhat.com> wrote:
> kmemleak detects the following memory leak when hot removing
> a network device:
>
> unreferenced object 0xffff888083f63600 (size 256):
> comm "kworker/0:1", pid 12, jiffies 4294831717 (age 1113.676s)
> hex dump (first 32 bytes):
> 00 40 c7 33 80 88 ff ff 00 00 00 00 10 00 00 00 .@.3............
> 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N..........
> backtrace:
> [<00000000d4a8f5be>] rndis_filter_device_add+0x117/0x11c0 [hv_netvsc]
> [<000000009c02d75b>] netvsc_probe+0x5e7/0xbf0 [hv_netvsc]
> [<00000000ddafce23>] vmbus_probe+0x74/0x170 [hv_vmbus]
> [<00000000046e64f1>] really_probe+0x22f/0xb50
> [<000000005cc35eb7>] driver_probe_device+0x25e/0x370
> [<0000000043c642b2>] bus_for_each_drv+0x11f/0x1b0
> [<000000005e3d09f0>] __device_attach+0x1c6/0x2f0
> [<00000000a72c362f>] bus_probe_device+0x1a6/0x260
> [<0000000008478399>] device_add+0x10a3/0x18e0
> [<00000000cf07b48c>] vmbus_device_register+0xe7/0x1e0 [hv_vmbus]
> [<00000000d46cf032>] vmbus_add_channel_work+0x8ab/0x1770 [hv_vmbus]
> [<000000002c94bb64>] process_one_work+0x919/0x17d0
> [<0000000096de6781>] worker_thread+0x87/0xb40
> [<00000000fbe7397e>] kthread+0x333/0x3f0
> [<000000004f844269>] ret_from_fork+0x3a/0x50
>
> rndis_filter_device_add() allocates an instance of struct rndis_device
> which never gets deallocated and rndis_filter_device_remove() sets
> net_device->extension which points to the rndis_device struct to NULL
> without ever freeing the structure first, leaving it dangling.
>
> This patch fixes this by freeing the structure before setting
> net_device->extension to NULL
>
> Signed-off-by: Mohammed Gamal <mgamal@redhat.com>
> ---
> drivers/net/hyperv/rndis_filter.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/hyperv/rndis_filter.c b/drivers/net/hyperv/rndis_filter.c
> index 857c4bea451c..d2e094f521a4 100644
> --- a/drivers/net/hyperv/rndis_filter.c
> +++ b/drivers/net/hyperv/rndis_filter.c
> @@ -1443,6 +1443,7 @@ void rndis_filter_device_remove(struct hv_device *dev,
> /* Halt and release the rndis device */
> rndis_filter_halt_device(net_dev, rndis_dev);
>
> + kfree(rndis_dev);
> net_dev->extension = NULL;
>
> netvsc_device_remove(dev);
That is one way, but maybe safer to just remove the line that sets
extension to NULL. That way netvsc_device_remove will clean it up:
netvsc_device_remove -> free_netvsc_device_rcu -> free_netvsc_device.
^ permalink raw reply
* [Patch v4 1/2] PCI: hv: Decouple the func definition in hv_dr_state from VSP message
From: longli @ 2020-01-13 20:08 UTC (permalink / raw)
To: K. Y. Srinivasan, Haiyang Zhang, Stephen Hemminger, Sasha Levin,
Lorenzo Pieralisi, Andrew Murray, Bjorn Helgaas, linux-hyperv,
linux-pci, linux-kernel
Cc: Long Li
From: Long Li <longli@microsoft.com>
hv_dr_state is used to find present PCI devices on the bus. The structure
reuses struct pci_function_description from VSP message to describe a
device.
To prepare support for pci_function_description v2, decouple this
dependence in hv_dr_state so it can work with both v1 and v2 VSP messages.
There is no functionality change.
Signed-off-by: Long Li <longli@microsoft.com>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
---
Changes
v2: Changed some spaces to tabs, changed failure code to -ENOMEM
v3: Revised comment for function hv_pci_devices_present(), reformatted patch title
v4: Fixed spelling
drivers/pci/controller/pci-hyperv.c | 101 +++++++++++++++++++---------
1 file changed, 70 insertions(+), 31 deletions(-)
diff --git a/drivers/pci/controller/pci-hyperv.c b/drivers/pci/controller/pci-hyperv.c
index f1f300218fab..3b3e1967cf08 100644
--- a/drivers/pci/controller/pci-hyperv.c
+++ b/drivers/pci/controller/pci-hyperv.c
@@ -507,10 +507,24 @@ struct hv_dr_work {
struct hv_pcibus_device *bus;
};
+struct hv_pcidev_description {
+ u16 v_id; /* vendor ID */
+ u16 d_id; /* device ID */
+ u8 rev;
+ u8 prog_intf;
+ u8 subclass;
+ u8 base_class;
+ u32 subsystem_id;
+ union win_slot_encoding win_slot;
+ u32 ser; /* serial number */
+ u32 flags;
+ u16 virtual_numa_node;
+};
+
struct hv_dr_state {
struct list_head list_entry;
u32 device_count;
- struct pci_function_description func[0];
+ struct hv_pcidev_description func[0];
};
enum hv_pcichild_state {
@@ -527,7 +541,7 @@ struct hv_pci_dev {
refcount_t refs;
enum hv_pcichild_state state;
struct pci_slot *pci_slot;
- struct pci_function_description desc;
+ struct hv_pcidev_description desc;
bool reported_missing;
struct hv_pcibus_device *hbus;
struct work_struct wrk;
@@ -1862,7 +1876,7 @@ static void q_resource_requirements(void *context, struct pci_response *resp,
* Return: Pointer to the new tracking struct
*/
static struct hv_pci_dev *new_pcichild_device(struct hv_pcibus_device *hbus,
- struct pci_function_description *desc)
+ struct hv_pcidev_description *desc)
{
struct hv_pci_dev *hpdev;
struct pci_child_message *res_req;
@@ -1973,7 +1987,7 @@ static void pci_devices_present_work(struct work_struct *work)
{
u32 child_no;
bool found;
- struct pci_function_description *new_desc;
+ struct hv_pcidev_description *new_desc;
struct hv_pci_dev *hpdev;
struct hv_pcibus_device *hbus;
struct list_head removed;
@@ -2090,43 +2104,26 @@ static void pci_devices_present_work(struct work_struct *work)
put_hvpcibus(hbus);
kfree(dr);
}
-
/**
- * hv_pci_devices_present() - Handles list of new children
+ * hv_pci_start_relations_work() - Queue work to start device discovery
* @hbus: Root PCI bus, as understood by this driver
- * @relations: Packet from host listing children
+ * @dr: The list of children returned from host
*
- * This function is invoked whenever a new list of devices for
- * this bus appears.
+ * Return: 0 on success, -errno on failure
*/
-static void hv_pci_devices_present(struct hv_pcibus_device *hbus,
- struct pci_bus_relations *relations)
+static int hv_pci_start_relations_work(struct hv_pcibus_device *hbus,
+ struct hv_dr_state *dr)
{
- struct hv_dr_state *dr;
struct hv_dr_work *dr_wrk;
- unsigned long flags;
bool pending_dr;
+ unsigned long flags;
dr_wrk = kzalloc(sizeof(*dr_wrk), GFP_NOWAIT);
if (!dr_wrk)
- return;
-
- dr = kzalloc(offsetof(struct hv_dr_state, func) +
- (sizeof(struct pci_function_description) *
- (relations->device_count)), GFP_NOWAIT);
- if (!dr) {
- kfree(dr_wrk);
- return;
- }
+ return -ENOMEM;
INIT_WORK(&dr_wrk->wrk, pci_devices_present_work);
dr_wrk->bus = hbus;
- dr->device_count = relations->device_count;
- if (dr->device_count != 0) {
- memcpy(dr->func, relations->func,
- sizeof(struct pci_function_description) *
- dr->device_count);
- }
spin_lock_irqsave(&hbus->device_list_lock, flags);
/*
@@ -2144,6 +2141,47 @@ static void hv_pci_devices_present(struct hv_pcibus_device *hbus,
get_hvpcibus(hbus);
queue_work(hbus->wq, &dr_wrk->wrk);
}
+
+ return 0;
+}
+
+/**
+ * hv_pci_devices_present() - Handle list of new children
+ * @hbus: Root PCI bus, as understood by this driver
+ * @relations: Packet from host listing children
+ *
+ * Process a new list of devices on the bus. The list of devices is
+ * discovered by VSP and sent to us via VSP message PCI_BUS_RELATIONS,
+ * whenever a new list of devices for this bus appears.
+ */
+static void hv_pci_devices_present(struct hv_pcibus_device *hbus,
+ struct pci_bus_relations *relations)
+{
+ struct hv_dr_state *dr;
+ int i;
+
+ dr = kzalloc(offsetof(struct hv_dr_state, func) +
+ (sizeof(struct hv_pcidev_description) *
+ (relations->device_count)), GFP_NOWAIT);
+
+ if (!dr)
+ return;
+
+ dr->device_count = relations->device_count;
+ for (i = 0; i < dr->device_count; i++) {
+ dr->func[i].v_id = relations->func[i].v_id;
+ dr->func[i].d_id = relations->func[i].d_id;
+ dr->func[i].rev = relations->func[i].rev;
+ dr->func[i].prog_intf = relations->func[i].prog_intf;
+ dr->func[i].subclass = relations->func[i].subclass;
+ dr->func[i].base_class = relations->func[i].base_class;
+ dr->func[i].subsystem_id = relations->func[i].subsystem_id;
+ dr->func[i].win_slot = relations->func[i].win_slot;
+ dr->func[i].ser = relations->func[i].ser;
+ }
+
+ if (hv_pci_start_relations_work(hbus, dr))
+ kfree(dr);
}
/**
@@ -3018,7 +3056,7 @@ static void hv_pci_bus_exit(struct hv_device *hdev)
struct pci_packet teardown_packet;
u8 buffer[sizeof(struct pci_message)];
} pkt;
- struct pci_bus_relations relations;
+ struct hv_dr_state *dr;
struct hv_pci_compl comp_pkt;
int ret;
@@ -3030,8 +3068,9 @@ static void hv_pci_bus_exit(struct hv_device *hdev)
return;
/* Delete any children which might still exist. */
- memset(&relations, 0, sizeof(relations));
- hv_pci_devices_present(hbus, &relations);
+ dr = kzalloc(sizeof(*dr), GFP_KERNEL);
+ if (dr && hv_pci_start_relations_work(hbus, dr))
+ kfree(dr);
ret = hv_send_resources_released(hdev);
if (ret)
--
2.17.1
^ permalink raw reply related
* [Patch v4 2/2] PCI: hv: Add support for protocol 1.3 and support PCI_BUS_RELATIONS2
From: longli @ 2020-01-13 20:08 UTC (permalink / raw)
To: K. Y. Srinivasan, Haiyang Zhang, Stephen Hemminger, Sasha Levin,
Lorenzo Pieralisi, Andrew Murray, Bjorn Helgaas, linux-hyperv,
linux-pci, linux-kernel
Cc: Long Li
In-Reply-To: <1578946101-74036-1-git-send-email-longli@linuxonhyperv.com>
From: Long Li <longli@microsoft.com>
Starting with Hyper-V PCI protocol version 1.3, the host VSP can send
PCI_BUS_RELATIONS2 and pass the vNUMA node information for devices on the
bus. The vNUMA node tells which guest NUMA node this device is on based
on guest VM configuration topology and physical device inforamtion.
Add code to negotiate v1.3 and process PCI_BUS_RELATIONS2.
Signed-off-by: Long Li <longli@microsoft.com>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
---
Changes
v2: Changed some spaces to tabs, added put_pcichild() after get_pcichild_wslot(), renamed pci_assign_numa_node() to hv_pci_assign_numa_node()
v4: Fixed spelling
drivers/pci/controller/pci-hyperv.c | 109 ++++++++++++++++++++++++++++
1 file changed, 109 insertions(+)
diff --git a/drivers/pci/controller/pci-hyperv.c b/drivers/pci/controller/pci-hyperv.c
index 3b3e1967cf08..147358fae8a2 100644
--- a/drivers/pci/controller/pci-hyperv.c
+++ b/drivers/pci/controller/pci-hyperv.c
@@ -63,6 +63,7 @@
enum pci_protocol_version_t {
PCI_PROTOCOL_VERSION_1_1 = PCI_MAKE_VERSION(1, 1), /* Win10 */
PCI_PROTOCOL_VERSION_1_2 = PCI_MAKE_VERSION(1, 2), /* RS1 */
+ PCI_PROTOCOL_VERSION_1_3 = PCI_MAKE_VERSION(1, 3), /* Vibranium */
};
#define CPU_AFFINITY_ALL -1ULL
@@ -72,6 +73,7 @@ enum pci_protocol_version_t {
* first.
*/
static enum pci_protocol_version_t pci_protocol_versions[] = {
+ PCI_PROTOCOL_VERSION_1_3,
PCI_PROTOCOL_VERSION_1_2,
PCI_PROTOCOL_VERSION_1_1,
};
@@ -124,6 +126,7 @@ enum pci_message_type {
PCI_RESOURCES_ASSIGNED2 = PCI_MESSAGE_BASE + 0x16,
PCI_CREATE_INTERRUPT_MESSAGE2 = PCI_MESSAGE_BASE + 0x17,
PCI_DELETE_INTERRUPT_MESSAGE2 = PCI_MESSAGE_BASE + 0x18, /* unused */
+ PCI_BUS_RELATIONS2 = PCI_MESSAGE_BASE + 0x19,
PCI_MESSAGE_MAXIMUM
};
@@ -169,6 +172,26 @@ struct pci_function_description {
u32 ser; /* serial number */
} __packed;
+enum pci_device_description_flags {
+ HV_PCI_DEVICE_FLAG_NONE = 0x0,
+ HV_PCI_DEVICE_FLAG_NUMA_AFFINITY = 0x1,
+};
+
+struct pci_function_description2 {
+ u16 v_id; /* vendor ID */
+ u16 d_id; /* device ID */
+ u8 rev;
+ u8 prog_intf;
+ u8 subclass;
+ u8 base_class;
+ u32 subsystem_id;
+ union win_slot_encoding win_slot;
+ u32 ser; /* serial number */
+ u32 flags;
+ u16 virtual_numa_node;
+ u16 reserved;
+} __packed;
+
/**
* struct hv_msi_desc
* @vector: IDT entry
@@ -304,6 +327,12 @@ struct pci_bus_relations {
struct pci_function_description func[0];
} __packed;
+struct pci_bus_relations2 {
+ struct pci_incoming_message incoming;
+ u32 device_count;
+ struct pci_function_description2 func[0];
+} __packed;
+
struct pci_q_res_req_response {
struct vmpacket_descriptor hdr;
s32 status; /* negative values are failures */
@@ -1417,6 +1446,7 @@ static void hv_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
break;
case PCI_PROTOCOL_VERSION_1_2:
+ case PCI_PROTOCOL_VERSION_1_3:
size = hv_compose_msi_req_v2(&ctxt.int_pkts.v2,
dest,
hpdev->desc.win_slot.slot,
@@ -1798,6 +1828,27 @@ static void hv_pci_remove_slots(struct hv_pcibus_device *hbus)
}
}
+/*
+ * Set NUMA node for the devices on the bus
+ */
+static void hv_pci_assign_numa_node(struct hv_pcibus_device *hbus)
+{
+ struct pci_dev *dev;
+ struct pci_bus *bus = hbus->pci_bus;
+ struct hv_pci_dev *hv_dev;
+
+ list_for_each_entry(dev, &bus->devices, bus_list) {
+ hv_dev = get_pcichild_wslot(hbus, devfn_to_wslot(dev->devfn));
+ if (!hv_dev)
+ continue;
+
+ if (hv_dev->desc.flags & HV_PCI_DEVICE_FLAG_NUMA_AFFINITY)
+ set_dev_node(&dev->dev, hv_dev->desc.virtual_numa_node);
+
+ put_pcichild(hv_dev);
+ }
+}
+
/**
* create_root_hv_pci_bus() - Expose a new root PCI bus
* @hbus: Root PCI bus, as understood by this driver
@@ -1820,6 +1871,7 @@ static int create_root_hv_pci_bus(struct hv_pcibus_device *hbus)
pci_lock_rescan_remove();
pci_scan_child_bus(hbus->pci_bus);
+ hv_pci_assign_numa_node(hbus);
pci_bus_assign_resources(hbus->pci_bus);
hv_pci_assign_slots(hbus);
pci_bus_add_devices(hbus->pci_bus);
@@ -2088,6 +2140,7 @@ static void pci_devices_present_work(struct work_struct *work)
*/
pci_lock_rescan_remove();
pci_scan_child_bus(hbus->pci_bus);
+ hv_pci_assign_numa_node(hbus);
hv_pci_assign_slots(hbus);
pci_unlock_rescan_remove();
break;
@@ -2184,6 +2237,46 @@ static void hv_pci_devices_present(struct hv_pcibus_device *hbus,
kfree(dr);
}
+/**
+ * hv_pci_devices_present2() - Handle list of new children
+ * @hbus: Root PCI bus, as understood by this driver
+ * @relations2: Packet from host listing children
+ *
+ * This function is the v2 version of hv_pci_devices_present()
+ */
+static void hv_pci_devices_present2(struct hv_pcibus_device *hbus,
+ struct pci_bus_relations2 *relations)
+{
+ struct hv_dr_state *dr;
+ int i;
+
+ dr = kzalloc(offsetof(struct hv_dr_state, func) +
+ (sizeof(struct hv_pcidev_description) *
+ (relations->device_count)), GFP_NOWAIT);
+
+ if (!dr)
+ return;
+
+ dr->device_count = relations->device_count;
+ for (i = 0; i < dr->device_count; i++) {
+ dr->func[i].v_id = relations->func[i].v_id;
+ dr->func[i].d_id = relations->func[i].d_id;
+ dr->func[i].rev = relations->func[i].rev;
+ dr->func[i].prog_intf = relations->func[i].prog_intf;
+ dr->func[i].subclass = relations->func[i].subclass;
+ dr->func[i].base_class = relations->func[i].base_class;
+ dr->func[i].subsystem_id = relations->func[i].subsystem_id;
+ dr->func[i].win_slot = relations->func[i].win_slot;
+ dr->func[i].ser = relations->func[i].ser;
+ dr->func[i].flags = relations->func[i].flags;
+ dr->func[i].virtual_numa_node =
+ relations->func[i].virtual_numa_node;
+ }
+
+ if (hv_pci_start_relations_work(hbus, dr))
+ kfree(dr);
+}
+
/**
* hv_eject_device_work() - Asynchronously handles ejection
* @work: Work struct embedded in internal device struct
@@ -2289,6 +2382,7 @@ static void hv_pci_onchannelcallback(void *context)
struct pci_response *response;
struct pci_incoming_message *new_message;
struct pci_bus_relations *bus_rel;
+ struct pci_bus_relations2 *bus_rel2;
struct pci_dev_inval_block *inval;
struct pci_dev_incoming *dev_message;
struct hv_pci_dev *hpdev;
@@ -2356,6 +2450,21 @@ static void hv_pci_onchannelcallback(void *context)
hv_pci_devices_present(hbus, bus_rel);
break;
+ case PCI_BUS_RELATIONS2:
+
+ bus_rel2 = (struct pci_bus_relations2 *)buffer;
+ if (bytes_recvd <
+ offsetof(struct pci_bus_relations2, func) +
+ (sizeof(struct pci_function_description2) *
+ (bus_rel2->device_count))) {
+ dev_err(&hbus->hdev->device,
+ "bus relations v2 too small\n");
+ break;
+ }
+
+ hv_pci_devices_present2(hbus, bus_rel2);
+ break;
+
case PCI_EJECT:
dev_message = (struct pci_dev_incoming *)buffer;
--
2.17.1
^ permalink raw reply related
* RE: [PATCH v2 0/4] hv_utils: Add the support of hibernation
From: Dexuan Cui @ 2020-01-13 22:21 UTC (permalink / raw)
To: KY Srinivasan, Haiyang Zhang, Stephen Hemminger,
sashal@kernel.org, Sasha Levin, linux-hyperv@vger.kernel.org,
Michael Kelley, vkuznets, linux-kernel@vger.kernel.org
In-Reply-To: <HK0P153MB0148968D9EFBFAE1E881674CBF350@HK0P153MB0148.APCP153.PROD.OUTLOOK.COM>
> From: Dexuan Cui
> Sent: Sunday, January 12, 2020 10:29 PM
>
> Hi,
> This is an updated version of the v1 patchset:
> https://lkml.org/lkml/2019/9/11/861
>
> Patch #1 is a new patch that makes the daemons more robust.
>
> Patch #2 is the same as v1.
>
> Patch #3 sends the host-initiated hibernation request to the user space via
> udev.
> (v1 used call_usermodehelper() and "/sbin/hyperv-hibernate".)
>
> Patch #4 handles fcopy/vss specially to avoid possible inconsistent states.
>
> Please review.
>
> Thanks!
>
> Dexuan Cui (4):
> Patch #1: Tools: hv: Reopen the devices if read() or write() returns errors
> Patch #2: hv_utils: Support host-initiated restart request
> Patch #3: hv_utils: Support host-initiated hibernation request
> Patch #4: hv_utils: Add the support of hibernation
Hi Vitaly,
I forgot to mention this for patch #4: IMO we don't need to add a new
HVUTIL_SUSPENDED state to the hvutil state machine, because:
When we reach util_suspend(), all the userspace processes have been
frozen: see kernel/power/hibernate.c: hibernate() -> freeze_processes() ->
try_to_freeze_tasks(true) -> freeze_task() -> fake_signal_wake_up(). When
try_to_freeze_tasks(true) returns 0, all the user-space processes must be
frozen in do_signal() -> get_signal() -> try_to_freeze() -> ... -> __refrigerator().
hibernate () -> hibernation_snapshot () -> dpm_suspend() -> ... ->
util_suspend() only runs after hibernate() -> freeze_processes(), so I'm
pretty sure we have no race condition with the user space daemon.
util_suspend() -> srv->util_pre_suspend() disables the tasklet and cancels any
pening work items, so there is no race in the kernel space, either.
Thanks,
-- Dexuan
^ permalink raw reply
* RE: [PATCH] scsi: storvsc: Correctly set number of hardware queues for IDE disk
From: Long Li @ 2020-01-14 0:09 UTC (permalink / raw)
To: Michael Kelley, longli@linuxonhyperv.com, KY Srinivasan,
Haiyang Zhang, Stephen Hemminger, Sasha Levin,
James E.J. Bottomley, Martin K. Petersen,
linux-hyperv@vger.kernel.org, linux-scsi@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <MW2PR2101MB105213EDB40D8974CF45A8B6D73A0@MW2PR2101MB1052.namprd21.prod.outlook.com>
>Subject: RE: [PATCH] scsi: storvsc: Correctly set number of hardware queues for
>IDE disk
>
>From: Long Li <longli@microsoft.com> Sent: Saturday, January 11, 2020 12:17
>AM
>>
>> Commit 0ed881027690 ("scsi: storvsc: setup 1:1 mapping between
>> hardware queue and CPU queue") introduced a regression for disks
>> attached to IDE. For these disks the host VSP only offers one VMBUS
>> channel. Setting multiple queues can overload the VMBUS channel and
>> result in performance drop for high queue depth workload on system
>> with large number of CPUs.
>>
>> Fix it by leaving the number of hardware queues to 1 (default value)
>> for IDE disks.
>>
>> Fixes: 0ed881027690 ("scsi: storvsc: setup 1:1 mapping between
>> hardware queue and CPU
>> queue")
>> Signed-off-by: Long Li <longli@microsoft.com>
>> ---
>> drivers/scsi/storvsc_drv.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
>> index f8faf8b3d965..992b28e40374 100644
>> --- a/drivers/scsi/storvsc_drv.c
>> +++ b/drivers/scsi/storvsc_drv.c
>> @@ -1842,9 +1842,11 @@ static int storvsc_probe(struct hv_device *device,
>> */
>> host->sg_tablesize = (stor_device->max_transfer_bytes >> PAGE_SHIFT);
>> /*
>> + * For non-IDE disks, the host supports multiple channels.
>> * Set the number of HW queues we are supporting.
>> */
>> - host->nr_hw_queues = num_present_cpus();
>> + if (dev_id->driver_data != IDE_GUID)
>
>This function already has a pre-computed value of this test in
>the local variable "dev_is_ide". It would be more consistent
>to just use it.
>
>Michael
I will send v2 to address this.
Long
>
>> + host->nr_hw_queues = num_present_cpus();
>>
>> /*
>> * Set the error handler work queue.
>> --
>> 2.20.1
^ permalink raw reply
* [Patch v2] scsi: storvsc: Correctly set number of hardware queues for IDE disk
From: longli @ 2020-01-14 0:08 UTC (permalink / raw)
To: K. Y. Srinivasan, Haiyang Zhang, Stephen Hemminger, Sasha Levin,
James E.J. Bottomley, Martin K. Petersen, linux-hyperv,
linux-scsi, linux-kernel
Cc: Long Li
From: Long Li <longli@microsoft.com>
Commit 0ed881027690 ("scsi: storvsc: setup 1:1 mapping between hardware queue and CPU queue")
introduced a regression for disks attached to IDE. For these disks the host VSP only offers
one VMBUS channel. Setting multiple queues can overload the VMBUS channel and result in
performance drop for high queue depth workload on system with large number of CPUs.
Fix it by leaving the number of hardware queues to 1 (default value) for IDE
disks.
Fixes: 0ed881027690 ("scsi: storvsc: setup 1:1 mapping between hardware queue and CPU queue")
Signed-off-by: Long Li <longli@microsoft.com>
Reviewed-by: Ming Lei <ming.lei@redhat.com>
---
Changes:
v2: Use pre-computed bool variable dev_is_ide
drivers/scsi/storvsc_drv.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index f8faf8b3d965..fb41636519ee 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -1842,9 +1842,11 @@ static int storvsc_probe(struct hv_device *device,
*/
host->sg_tablesize = (stor_device->max_transfer_bytes >> PAGE_SHIFT);
/*
+ * For non-IDE disks, the host supports multiple channels.
* Set the number of HW queues we are supporting.
*/
- host->nr_hw_queues = num_present_cpus();
+ if (!dev_is_ide)
+ host->nr_hw_queues = num_present_cpus();
/*
* Set the error handler work queue.
--
2.20.1
^ permalink raw reply related
* [PATCH net]: hv_sock: Remove the accept port restriction
From: Sunil Muthuswamy @ 2020-01-14 0:52 UTC (permalink / raw)
To: netdev@vger.kernel.org, David S. Miller, Dexuan Cui
Cc: Stephen Hemminger, Sasha Levin, linux-hyperv@vger.kernel.org,
linux-kernel@vger.kernel.org
Currently, hv_sock restricts the port the guest socket can accept
connections on. hv_sock divides the socket port namespace into two parts
for server side (listening socket), 0-0x7FFFFFFF & 0x80000000-0xFFFFFFFF
(there are no restrictions on client port namespace). The first part
(0-0x7FFFFFFF) is reserved for sockets where connections can be accepted.
The second part (0x80000000-0xFFFFFFFF) is reserved for allocating ports
for the peer (host) socket, once a connection is accepted.
This reservation of the port namespace is specific to hv_sock and not
known by the generic vsock library (ex: af_vsock). This is problematic
because auto-binds/ephemeral ports are handled by the generic vsock
library and it has no knowledge of this port reservation and could
allocate a port that is not compatible with hv_sock (and legitimately so).
The issue hasn't surfaced so far because the auto-bind code of vsock
(__vsock_bind_stream) prior to the change 'VSOCK: bind to random port for
VMADDR_PORT_ANY' would start walking up from LAST_RESERVED_PORT (1023) and
start assigning ports. That will take a large number of iterations to hit
0x7FFFFFFF. But, after the above change to randomize port selection, the
issue has started coming up more frequently.
There has really been no good reason to have this port reservation logic
in hv_sock from the get go. Reserving a local port for peer ports is not
how things are handled generally. Peer ports should reflect the peer port.
This fixes the issue by lifting the port reservation, and also returns the
right peer port. Since the code converts the GUID to the peer port (by
using the first 4 bytes), there is a possibility of conflicts, but that
seems like a reasonable risk to take, given this is limited to vsock and
that only applies to all local sockets.
Signed-off-by: Sunil Muthuswamy <sunilmut@microsoft.com>
---
net/vmw_vsock/hyperv_transport.c | 65 +++-----------------------------
1 file changed, 6 insertions(+), 59 deletions(-)
diff --git a/net/vmw_vsock/hyperv_transport.c b/net/vmw_vsock/hyperv_transport.c
index b3bdae74c243..3492c021925f 100644
--- a/net/vmw_vsock/hyperv_transport.c
+++ b/net/vmw_vsock/hyperv_transport.c
@@ -138,28 +138,15 @@ struct hvsock {
****************************************************************************
* The only valid Service GUIDs, from the perspectives of both the host and *
* Linux VM, that can be connected by the other end, must conform to this *
- * format: <port>-facb-11e6-bd58-64006a7986d3, and the "port" must be in *
- * this range [0, 0x7FFFFFFF]. *
+ * format: <port>-facb-11e6-bd58-64006a7986d3. *
****************************************************************************
*
* When we write apps on the host to connect(), the GUID ServiceID is used.
* When we write apps in Linux VM to connect(), we only need to specify the
* port and the driver will form the GUID and use that to request the host.
*
- * From the perspective of Linux VM:
- * 1. the local ephemeral port (i.e. the local auto-bound port when we call
- * connect() without explicit bind()) is generated by __vsock_bind_stream(),
- * and the range is [1024, 0xFFFFFFFF).
- * 2. the remote ephemeral port (i.e. the auto-generated remote port for
- * a connect request initiated by the host's connect()) is generated by
- * hvs_remote_addr_init() and the range is [0x80000000, 0xFFFFFFFF).
*/
-#define MAX_LISTEN_PORT ((u32)0x7FFFFFFF)
-#define MAX_VM_LISTEN_PORT MAX_LISTEN_PORT
-#define MAX_HOST_LISTEN_PORT MAX_LISTEN_PORT
-#define MIN_HOST_EPHEMERAL_PORT (MAX_HOST_LISTEN_PORT + 1)
-
/* 00000000-facb-11e6-bd58-64006a7986d3 */
static const guid_t srv_id_template =
GUID_INIT(0x00000000, 0xfacb, 0x11e6, 0xbd, 0x58,
@@ -184,34 +171,6 @@ static void hvs_addr_init(struct sockaddr_vm *addr, const guid_t *svr_id)
vsock_addr_init(addr, VMADDR_CID_ANY, port);
}
-static void hvs_remote_addr_init(struct sockaddr_vm *remote,
- struct sockaddr_vm *local)
-{
- static u32 host_ephemeral_port = MIN_HOST_EPHEMERAL_PORT;
- struct sock *sk;
-
- /* Remote peer is always the host */
- vsock_addr_init(remote, VMADDR_CID_HOST, VMADDR_PORT_ANY);
-
- while (1) {
- /* Wrap around ? */
- if (host_ephemeral_port < MIN_HOST_EPHEMERAL_PORT ||
- host_ephemeral_port == VMADDR_PORT_ANY)
- host_ephemeral_port = MIN_HOST_EPHEMERAL_PORT;
-
- remote->svm_port = host_ephemeral_port++;
-
- sk = vsock_find_connected_socket(remote, local);
- if (!sk) {
- /* Found an available ephemeral port */
- return;
- }
-
- /* Release refcnt got in vsock_find_connected_socket */
- sock_put(sk);
- }
-}
-
static void hvs_set_channel_pending_send_size(struct vmbus_channel *chan)
{
set_channel_pending_send_size(chan,
@@ -341,12 +300,7 @@ static void hvs_open_connection(struct vmbus_channel *chan)
if_type = &chan->offermsg.offer.if_type;
if_instance = &chan->offermsg.offer.if_instance;
conn_from_host = chan->offermsg.offer.u.pipe.user_def[0];
-
- /* The host or the VM should only listen on a port in
- * [0, MAX_LISTEN_PORT]
- */
- if (!is_valid_srv_id(if_type) ||
- get_port_by_srv_id(if_type) > MAX_LISTEN_PORT)
+ if (!is_valid_srv_id(if_type))
return;
hvs_addr_init(&addr, conn_from_host ? if_type : if_instance);
@@ -371,8 +325,11 @@ static void hvs_open_connection(struct vmbus_channel *chan)
vnew = vsock_sk(new);
hvs_addr_init(&vnew->local_addr, if_type);
- hvs_remote_addr_init(&vnew->remote_addr, &vnew->local_addr);
+ /* Remote peer is always the host */
+ vsock_addr_init(&vnew->remote_addr,
+ VMADDR_CID_HOST, VMADDR_PORT_ANY);
+ vnew->remote_addr.svm_port = get_port_by_srv_id(if_instance);
ret = vsock_assign_transport(vnew, vsock_sk(sk));
/* Transport assigned (looking at remote_addr) must be the
* same where we received the request.
@@ -766,16 +723,6 @@ static bool hvs_stream_is_active(struct vsock_sock *vsk)
static bool hvs_stream_allow(u32 cid, u32 port)
{
- /* The host's port range [MIN_HOST_EPHEMERAL_PORT, 0xFFFFFFFF) is
- * reserved as ephemeral ports, which are used as the host's ports
- * when the host initiates connections.
- *
- * Perform this check in the guest so an immediate error is produced
- * instead of a timeout.
- */
- if (port > MAX_HOST_LISTEN_PORT)
- return false;
-
if (cid == VMADDR_CID_HOST)
return true;
--
2.17.1
^ permalink raw reply related
* [PATCH] x86/Hyper-V: Balloon up according to request page number
From: lantianyu1986 @ 2020-01-14 7:44 UTC (permalink / raw)
To: tglx, mingo, bp, hpa, x86, dave.hansen, luto, peterz, kys,
haiyangz, sthemmin, sashal, akpm, michael.h.kelley, decui
Cc: Tianyu Lan, linux-kernel, linux-hyperv, linux-mm, vkuznets,
stable
From: Tianyu Lan <Tianyu.Lan@microsoft.com>
Current code has assumption that balloon request memory size aligns
with 2MB. But actually Hyper-V doesn't guarantee such alignment. When
balloon driver receives non-aligned balloon request, it produces warning
and balloon up more memory than requested in order to keep 2MB alignment.
Remove the warning and balloon up memory according to actual requested
memory size.
Fixes: f6712238471a ("hv: hv_balloon: avoid memory leak on alloc_error of 2MB memory block")
Cc: stable@vger.kernel.org
Signed-off-by: Tianyu Lan <Tianyu.Lan@microsoft.com>
---
drivers/hv/hv_balloon.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
index 7f3e7ab22d5d..38ad0e44e927 100644
--- a/drivers/hv/hv_balloon.c
+++ b/drivers/hv/hv_balloon.c
@@ -1684,7 +1684,7 @@ static unsigned int alloc_balloon_pages(struct hv_dynmem_device *dm,
if (num_pages < alloc_unit)
return 0;
- for (i = 0; (i * alloc_unit) < num_pages; i++) {
+ for (i = 0; i < num_pages / alloc_unit; i++) {
if (bl_resp->hdr.size + sizeof(union dm_mem_page_range) >
HV_HYP_PAGE_SIZE)
return i * alloc_unit;
@@ -1722,7 +1722,7 @@ static unsigned int alloc_balloon_pages(struct hv_dynmem_device *dm,
}
- return num_pages;
+ return i * alloc_unit;
}
static void balloon_up(union dm_msg_info *msg_info)
@@ -1737,9 +1737,6 @@ static void balloon_up(union dm_msg_info *msg_info)
long avail_pages;
unsigned long floor;
- /* The host balloons pages in 2M granularity. */
- WARN_ON_ONCE(num_pages % PAGES_IN_2M != 0);
-
/*
* We will attempt 2M allocations. However, if we fail to
* allocate 2M chunks, we will go back to PAGE_SIZE allocations.
--
2.14.5
^ permalink raw reply related
* Re: [PATCH] x86/Hyper-V: Balloon up according to request page number
From: Vitaly Kuznetsov @ 2020-01-14 9:30 UTC (permalink / raw)
To: lantianyu1986
Cc: linux-kernel, linux-hyperv, linux-mm, stable, tglx, mingo, bp,
hpa, x86, dave.hansen, luto, peterz, kys, haiyangz, sthemmin,
sashal, akpm, michael.h.kelley, decui
In-Reply-To: <20200114074435.12732-1-Tianyu.Lan@microsoft.com>
lantianyu1986@gmail.com writes:
> From: Tianyu Lan <Tianyu.Lan@microsoft.com>
>
> Current code has assumption that balloon request memory size aligns
> with 2MB. But actually Hyper-V doesn't guarantee such alignment. When
> balloon driver receives non-aligned balloon request, it produces warning
> and balloon up more memory than requested in order to keep 2MB alignment.
> Remove the warning and balloon up memory according to actual requested
> memory size.
>
> Fixes: f6712238471a ("hv: hv_balloon: avoid memory leak on alloc_error of 2MB memory block")
> Cc: stable@vger.kernel.org
> Signed-off-by: Tianyu Lan <Tianyu.Lan@microsoft.com>
> ---
> drivers/hv/hv_balloon.c | 7 ++-----
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
> index 7f3e7ab22d5d..38ad0e44e927 100644
> --- a/drivers/hv/hv_balloon.c
> +++ b/drivers/hv/hv_balloon.c
> @@ -1684,7 +1684,7 @@ static unsigned int alloc_balloon_pages(struct hv_dynmem_device *dm,
> if (num_pages < alloc_unit)
> return 0;
>
> - for (i = 0; (i * alloc_unit) < num_pages; i++) {
> + for (i = 0; i < num_pages / alloc_unit; i++) {
> if (bl_resp->hdr.size + sizeof(union dm_mem_page_range) >
> HV_HYP_PAGE_SIZE)
> return i * alloc_unit;
> @@ -1722,7 +1722,7 @@ static unsigned int alloc_balloon_pages(struct hv_dynmem_device *dm,
>
> }
>
> - return num_pages;
> + return i * alloc_unit;
> }
>
> static void balloon_up(union dm_msg_info *msg_info)
> @@ -1737,9 +1737,6 @@ static void balloon_up(union dm_msg_info *msg_info)
> long avail_pages;
> unsigned long floor;
>
> - /* The host balloons pages in 2M granularity. */
> - WARN_ON_ONCE(num_pages % PAGES_IN_2M != 0);
> -
> /*
> * We will attempt 2M allocations. However, if we fail to
> * allocate 2M chunks, we will go back to PAGE_SIZE allocations.
This looks correct but I've noticed we also have
/* Refuse to balloon below the floor, keep the 2M granularity. */
if (avail_pages < num_pages || avail_pages - num_pages < floor) {
pr_warn("Balloon request will be partially fulfilled. %s\n",
avail_pages < num_pages ? "Not enough memory." :
"Balloon floor reached.");
num_pages = avail_pages > floor ? (avail_pages - floor) : 0;
num_pages -= num_pages % PAGES_IN_2M;
}
in balloon_up(). If 2M granularity is not guaranteed in the first place
we can't keep it.
Also, when alloc_balloon_pages() is called with 2M alloc_unit and the
region is not 2M aligned, it will return someething < num_pages, the
next condition, however, only checks for 0:
if (alloc_unit != 1 && num_ballooned == 0) {
alloc_unit = 1;
continue;
}
we will proceed to sending a response to server and try doing next
iteration by calling alloc_balloon_pages() with 2M alloc_unit again,
this will finally return 0 and we will switch to 4k. I think we can
optimize this to:
if (alloc_unit != 1 && num_ballooned != num_pages) {
alloc_unit = 1;
continue;
}
--
Vitaly
^ permalink raw reply
* Re: [EXTERNAL] Re: [RFC PATCH V2 2/10] mm: expose is_mem_section_removable() symbol
From: Michal Hocko @ 2020-01-14 9:50 UTC (permalink / raw)
To: Tianyu Lan
Cc: David Hildenbrand, lantianyu1986@gmail.com, KY Srinivasan,
Haiyang Zhang, Stephen Hemminger, sashal@kernel.org,
akpm@linux-foundation.org, Michael Kelley,
linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, vkuznets, eric.devolder@oracle.com,
vbabka@suse.cz, osalvador@suse.de, Pasha Tatashin,
rppt@linux.ibm.com
In-Reply-To: <SG2P153MB0349F85FB0C1C02F55391F6D92350@SG2P153MB0349.APCP153.PROD.OUTLOOK.COM>
On Mon 13-01-20 14:49:38, Tianyu Lan wrote:
> Hi David & Michal:
> Thanks for your review. Some memory blocks are not suitable for hot-plug.
> If not check memory block's removable, offline_pages() will report some failure error
> e.g, "failed due to memory holes" and "failure to isolate range". I think the check maybe
> added into offline_and_remove_memory()? This may help to not create/expose a new
> interface to do such check in module.
Why is a log message a problem in the first place. The operation has
failed afterall. Does the driver try to offline an arbitrary memory?
Could you describe your usecase in more details please?
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* [PATCH v2] hv_netvsc: Fix memory leak when removing rndis device
From: Mohammed Gamal @ 2020-01-14 13:09 UTC (permalink / raw)
To: linux-hyperv, sthemmin, haiyangz, netdev
Cc: kys, sashal, vkuznets, cavery, linux-kernel, Mohammed Gamal
kmemleak detects the following memory leak when hot removing
a network device:
unreferenced object 0xffff888083f63600 (size 256):
comm "kworker/0:1", pid 12, jiffies 4294831717 (age 1113.676s)
hex dump (first 32 bytes):
00 40 c7 33 80 88 ff ff 00 00 00 00 10 00 00 00 .@.3............
00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N..........
backtrace:
[<00000000d4a8f5be>] rndis_filter_device_add+0x117/0x11c0 [hv_netvsc]
[<000000009c02d75b>] netvsc_probe+0x5e7/0xbf0 [hv_netvsc]
[<00000000ddafce23>] vmbus_probe+0x74/0x170 [hv_vmbus]
[<00000000046e64f1>] really_probe+0x22f/0xb50
[<000000005cc35eb7>] driver_probe_device+0x25e/0x370
[<0000000043c642b2>] bus_for_each_drv+0x11f/0x1b0
[<000000005e3d09f0>] __device_attach+0x1c6/0x2f0
[<00000000a72c362f>] bus_probe_device+0x1a6/0x260
[<0000000008478399>] device_add+0x10a3/0x18e0
[<00000000cf07b48c>] vmbus_device_register+0xe7/0x1e0 [hv_vmbus]
[<00000000d46cf032>] vmbus_add_channel_work+0x8ab/0x1770 [hv_vmbus]
[<000000002c94bb64>] process_one_work+0x919/0x17d0
[<0000000096de6781>] worker_thread+0x87/0xb40
[<00000000fbe7397e>] kthread+0x333/0x3f0
[<000000004f844269>] ret_from_fork+0x3a/0x50
rndis_filter_device_add() allocates an instance of struct rndis_device
which never gets deallocated as rndis_filter_device_remove() sets
net_device->extension which points to the rndis_device struct to NULL,
leaving the rndis_device dangling.
Since net_device->extension is eventually freed in free_netvsc_device(),
we refrain from setting it to NULL inside rndis_filter_device_remove()
Signed-off-by: Mohammed Gamal <mgamal@redhat.com>
---
drivers/net/hyperv/rndis_filter.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/hyperv/rndis_filter.c b/drivers/net/hyperv/rndis_filter.c
index 857c4bea451c..e66d77dc28c8 100644
--- a/drivers/net/hyperv/rndis_filter.c
+++ b/drivers/net/hyperv/rndis_filter.c
@@ -1443,8 +1443,6 @@ void rndis_filter_device_remove(struct hv_device *dev,
/* Halt and release the rndis device */
rndis_filter_halt_device(net_dev, rndis_dev);
- net_dev->extension = NULL;
-
netvsc_device_remove(dev);
}
--
2.21.0
^ permalink raw reply related
* RE: [PATCH v2] hv_netvsc: Fix memory leak when removing rndis device
From: Haiyang Zhang @ 2020-01-14 13:20 UTC (permalink / raw)
To: Mohammed Gamal, linux-hyperv@vger.kernel.org, Stephen Hemminger,
netdev@vger.kernel.org
Cc: KY Srinivasan, sashal@kernel.org, vkuznets, cavery,
linux-kernel@vger.kernel.org
In-Reply-To: <20200114130950.6962-1-mgamal@redhat.com>
> -----Original Message-----
> From: Mohammed Gamal <mgamal@redhat.com>
> Sent: Tuesday, January 14, 2020 8:10 AM
> To: linux-hyperv@vger.kernel.org; Stephen Hemminger
> <sthemmin@microsoft.com>; Haiyang Zhang <haiyangz@microsoft.com>;
> netdev@vger.kernel.org
> Cc: KY Srinivasan <kys@microsoft.com>; sashal@kernel.org; vkuznets
> <vkuznets@redhat.com>; cavery <cavery@redhat.com>; linux-
> kernel@vger.kernel.org; Mohammed Gamal <mgamal@redhat.com>
> Subject: [PATCH v2] hv_netvsc: Fix memory leak when removing rndis device
>
> kmemleak detects the following memory leak when hot removing a network
> device:
>
> unreferenced object 0xffff888083f63600 (size 256):
> comm "kworker/0:1", pid 12, jiffies 4294831717 (age 1113.676s)
> hex dump (first 32 bytes):
> 00 40 c7 33 80 88 ff ff 00 00 00 00 10 00 00 00 .@.3............
> 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N..........
> backtrace:
> [<00000000d4a8f5be>] rndis_filter_device_add+0x117/0x11c0 [hv_netvsc]
> [<000000009c02d75b>] netvsc_probe+0x5e7/0xbf0 [hv_netvsc]
> [<00000000ddafce23>] vmbus_probe+0x74/0x170 [hv_vmbus]
> [<00000000046e64f1>] really_probe+0x22f/0xb50
> [<000000005cc35eb7>] driver_probe_device+0x25e/0x370
> [<0000000043c642b2>] bus_for_each_drv+0x11f/0x1b0
> [<000000005e3d09f0>] __device_attach+0x1c6/0x2f0
> [<00000000a72c362f>] bus_probe_device+0x1a6/0x260
> [<0000000008478399>] device_add+0x10a3/0x18e0
> [<00000000cf07b48c>] vmbus_device_register+0xe7/0x1e0 [hv_vmbus]
> [<00000000d46cf032>] vmbus_add_channel_work+0x8ab/0x1770 [hv_vmbus]
> [<000000002c94bb64>] process_one_work+0x919/0x17d0
> [<0000000096de6781>] worker_thread+0x87/0xb40
> [<00000000fbe7397e>] kthread+0x333/0x3f0
> [<000000004f844269>] ret_from_fork+0x3a/0x50
>
> rndis_filter_device_add() allocates an instance of struct rndis_device which
> never gets deallocated as rndis_filter_device_remove() sets net_device-
> >extension which points to the rndis_device struct to NULL, leaving the
> rndis_device dangling.
>
> Since net_device->extension is eventually freed in free_netvsc_device(), we
> refrain from setting it to NULL inside rndis_filter_device_remove()
>
> Signed-off-by: Mohammed Gamal <mgamal@redhat.com>
> ---
> drivers/net/hyperv/rndis_filter.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/net/hyperv/rndis_filter.c b/drivers/net/hyperv/rndis_filter.c
> index 857c4bea451c..e66d77dc28c8 100644
> --- a/drivers/net/hyperv/rndis_filter.c
> +++ b/drivers/net/hyperv/rndis_filter.c
> @@ -1443,8 +1443,6 @@ void rndis_filter_device_remove(struct hv_device
> *dev,
> /* Halt and release the rndis device */
> rndis_filter_halt_device(net_dev, rndis_dev);
>
> - net_dev->extension = NULL;
> -
> netvsc_device_remove(dev);
Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
^ permalink raw reply
* Re: [PATCH net]: hv_sock: Remove the accept port restriction
From: David Miller @ 2020-01-14 19:51 UTC (permalink / raw)
To: sunilmut; +Cc: netdev, decui, sthemmin, sashal, linux-hyperv, linux-kernel
In-Reply-To: <SN4PR2101MB08808AAFCEB4E8FC178A4B79C0340@SN4PR2101MB0880.namprd21.prod.outlook.com>
From: Sunil Muthuswamy <sunilmut@microsoft.com>
Date: Tue, 14 Jan 2020 00:52:14 +0000
> Currently, hv_sock restricts the port the guest socket can accept
> connections on. hv_sock divides the socket port namespace into two parts
> for server side (listening socket), 0-0x7FFFFFFF & 0x80000000-0xFFFFFFFF
> (there are no restrictions on client port namespace). The first part
> (0-0x7FFFFFFF) is reserved for sockets where connections can be accepted.
> The second part (0x80000000-0xFFFFFFFF) is reserved for allocating ports
> for the peer (host) socket, once a connection is accepted.
> This reservation of the port namespace is specific to hv_sock and not
> known by the generic vsock library (ex: af_vsock). This is problematic
> because auto-binds/ephemeral ports are handled by the generic vsock
> library and it has no knowledge of this port reservation and could
> allocate a port that is not compatible with hv_sock (and legitimately so).
> The issue hasn't surfaced so far because the auto-bind code of vsock
> (__vsock_bind_stream) prior to the change 'VSOCK: bind to random port for
> VMADDR_PORT_ANY' would start walking up from LAST_RESERVED_PORT (1023) and
> start assigning ports. That will take a large number of iterations to hit
> 0x7FFFFFFF. But, after the above change to randomize port selection, the
> issue has started coming up more frequently.
> There has really been no good reason to have this port reservation logic
> in hv_sock from the get go. Reserving a local port for peer ports is not
> how things are handled generally. Peer ports should reflect the peer port.
> This fixes the issue by lifting the port reservation, and also returns the
> right peer port. Since the code converts the GUID to the peer port (by
> using the first 4 bytes), there is a possibility of conflicts, but that
> seems like a reasonable risk to take, given this is limited to vsock and
> that only applies to all local sockets.
>
> Signed-off-by: Sunil Muthuswamy <sunilmut@microsoft.com>
Applied.
^ permalink raw reply
* Re: [PATCH][RESEND] video: hyperv_fb: Fix hibernation for the deferred IO feature
From: Bartlomiej Zolnierkiewicz @ 2020-01-15 13:34 UTC (permalink / raw)
To: Sasha Levin
Cc: Dexuan Cui, kys, haiyangz, sthemmin, linux-hyperv, dri-devel,
linux-fbdev, linux-kernel, mikelley, Alexander.Levin, weh
In-Reply-To: <20200111162957.GK1706@sasha-vm>
On 1/11/20 5:29 PM, Sasha Levin wrote:
> On Mon, Jan 06, 2020 at 02:41:51PM -0800, Dexuan Cui wrote:
>> fb_deferred_io_work() can access the vmbus ringbuffer by calling
>> fbdefio->deferred_io() -> synthvid_deferred_io() -> synthvid_update().
>>
>> Because the vmbus ringbuffer is inaccessible between hvfb_suspend()
>> and hvfb_resume(), we must cancel info->deferred_work before calling
>> vmbus_close() and then reschedule it after we reopen the channel
>> in hvfb_resume().
>>
>> Fixes: a4ddb11d297e ("video: hyperv: hyperv_fb: Support deferred IO for Hyper-V frame buffer driver")
>> Fixes: 824946a8b6fb ("video: hyperv_fb: Add the support of hibernation")
>> Signed-off-by: Dexuan Cui <decui@microsoft.com>
>> Reviewed-by: Wei Hu <weh@microsoft.com>
>> ---
>>
>> This is a RESEND of https://protect2.fireeye.com/url?k=a9db9902-f41598d1-a9da124d-000babff317b-c1ee475745c278a5&u=https://lkml.org/lkml/2019/11/20/73 .
>>
>> The only change is the addition of Wei's Review-ed-by.
>>
>> Please review.
>>
>> If it looks good, Sasha Levin, can you please pick it up via the
>> hyperv/linux.git tree, as you did last time for this driver?
>
> Like with the input driver, if the relevant maintainers here are okay
> with this type of patches going through the hyperv tree I'll be happy to
> do it, otherwise I need an explicit ack from them on this patch.
Yes, I'm fine with hyperv_fb driver patches going through hyperv tree.
Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* Re: [PATCH][next] video: hyperv: hyperv_fb: fix indentation issue
From: Bartlomiej Zolnierkiewicz @ 2020-01-15 14:36 UTC (permalink / raw)
To: Colin King
Cc: K . Y . Srinivasan, Haiyang Zhang, Stephen Hemminger, Sasha Levin,
linux-hyperv, dri-devel, linux-fbdev, kernel-janitors,
linux-kernel
In-Reply-To: <20191114172720.322023-1-colin.king@canonical.com>
On 11/14/19 6:27 PM, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> There is a block of statements that are indented
> too deeply, remove the extraneous tabs.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Patch queued for v5.6, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
> drivers/video/fbdev/hyperv_fb.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
> index 4cd27e5172a1..5fcf4bdf85ab 100644
> --- a/drivers/video/fbdev/hyperv_fb.c
> +++ b/drivers/video/fbdev/hyperv_fb.c
> @@ -582,8 +582,8 @@ static int synthvid_get_supported_resolution(struct hv_device *hdev)
> t = wait_for_completion_timeout(&par->wait, VSP_TIMEOUT);
> if (!t) {
> pr_err("Time out on waiting resolution response\n");
> - ret = -ETIMEDOUT;
> - goto out;
> + ret = -ETIMEDOUT;
> + goto out;
> }
>
> if (msg->resolution_resp.resolution_count == 0) {
>
^ permalink raw reply
* Re: [PATCH v4] video: hyperv: hyperv_fb: Use physical memory for fb on HyperV Gen 1 VMs.
From: Bartlomiej Zolnierkiewicz @ 2020-01-15 15:16 UTC (permalink / raw)
To: Dexuan Cui
Cc: Michael Kelley, Wei Hu, KY Srinivasan, Haiyang Zhang,
Stephen Hemminger, sashal@kernel.org, hch@lst.de,
m.szyprowski@samsung.com, mchehab+samsung@kernel.org,
sam@ravnborg.org, gregkh@linuxfoundation.org,
alexandre.belloni@bootlin.com, info@metux.net, arnd@arndb.de,
dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org,
kbuild test robot
In-Reply-To: <HK0P153MB0148F18913BEA45144AF8443BF3C0@HK0P153MB0148.APCP153.PROD.OUTLOOK.COM>
On 1/6/20 11:37 PM, Dexuan Cui wrote:
>> From: Michael Kelley <mikelley@microsoft.com>
>> Sent: Monday, December 9, 2019 8:33 AM
>> To: Wei Hu <weh@microsoft.com>; b.zolnierkie@samsung.com; KY
>> Srinivasan <kys@microsoft.com>; Haiyang Zhang <haiyangz@microsoft.com>;
>> Stephen Hemminger <sthemmin@microsoft.com>; sashal@kernel.org;
>> hch@lst.de; m.szyprowski@samsung.com; mchehab+samsung@kernel.org;
>> sam@ravnborg.org; gregkh@linuxfoundation.org;
>> alexandre.belloni@bootlin.com; info@metux.net; arnd@arndb.de;
>> dri-devel@lists.freedesktop.org; linux-fbdev@vger.kernel.org;
>> linux-kernel@vger.kernel.org; linux-hyperv@vger.kernel.org; Dexuan Cui
>> <decui@microsoft.com>
>> Cc: kbuild test robot <lkp@intel.com>
>> Subject: RE: [PATCH v4] video: hyperv: hyperv_fb: Use physical memory for
>> fb on HyperV Gen 1 VMs.
>>
>> From: Wei Hu <weh@microsoft.com> Sent: Sunday, December 8, 2019 11:58
>> PM
>>>
>>> On Hyper-V, Generation 1 VMs can directly use VM's physical memory for
>>> their framebuffers. This can improve the efficiency of framebuffer and
>>> overall performance for VM. The physical memory assigned to framebuffer
>>> must be contiguous. We use CMA allocator to get contiguous physicial
>>> memory when the framebuffer size is greater than 4MB. For size under
>>> 4MB, we use alloc_pages to achieve this.
>>>
>>> To enable framebuffer memory allocation from CMA, supply a kernel
>>> parameter to give enough space to CMA allocator at boot time. For
>>> example:
>>> cma=130m
>>> This gives 130MB memory to CAM allocator that can be allocated to
>>> framebuffer. If this fails, we fall back to the old way of using
>>> mmio for framebuffer.
>>>
>>> Reported-by: kbuild test robot <lkp@intel.com>
>>> Signed-off-by: Wei Hu <weh@microsoft.com>
>>> ---
>>> v2: Incorporated review comments form hch@lst.de, Michael Kelley
>> and
>>> Dexuan Cui
>>> - Use dma_alloc_coherent to allocate large contiguous memory
>>> - Use phys_addr_t for physical addresses
>>> - Corrected a few spelling errors and minor cleanups
>>> - Also tested on 32 bit Ubuntu guest
>>> v3: Fixed a build issue reported by kbuild test robot and incorported
>>> some review comments from Michael Kelley
>>> - Add CMA check to avoid link failure
>>> - Fixed small memory leak introduced by alloc_apertures
>>> - Cleaned up so code
>>> v4: Removed request_pages variable as it is no longer needed
>>>
>>> drivers/video/fbdev/Kconfig | 1 +
>>> drivers/video/fbdev/hyperv_fb.c | 182
>> +++++++++++++++++++++++++-------
>>> 2 files changed, 144 insertions(+), 39 deletions(-)
>>>
>>
>> Reviewed-by: Michael Kelley <mikelley@microsoft.com>
>
> Tested-by: Dexuan Cui <decui@microsoft.com>
>
> For a Gen-1 VM running on recent Hyper-V hosts, this patch can greatly
> reduce the CPU utilization because it avoids the slow data copy from the
> shadow framebuffer to the MMIO framebuffer, and hence it resolves the
> "blurred screen" issue when we output a lot of characters on the text-mode
> ternimal (e.g. "dmesg").
Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ 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