From: Dexuan Cui <decui@microsoft.com> Date: 2019-09-05 23:01:17
This patchset (consisting of 9 patches) was part of the v4 patchset (consisting
of 12 patches):
https://lkml.org/lkml/2019/9/2/894
The other 3 patches in v4 are posted in another patchset, which will go
through the tip.git tree.
All the 9 patches here are now rebased to the hyperv tree's hyperv-next branch:
https://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux.git/log/?h=hyperv-next
, and all the 9 patches have Michael Kelley's Signed-off-by's.
Please review.
Thanks!
Dexuan
Dexuan Cui (9):
Drivers: hv: vmbus: Break out synic enable and disable operations
Drivers: hv: vmbus: Suspend/resume the synic for hibernation
Drivers: hv: vmbus: Add a helper function is_sub_channel()
Drivers: hv: vmbus: Implement suspend/resume for VSC drivers for
hibernation
Drivers: hv: vmbus: Ignore the offers when resuming from hibernation
Drivers: hv: vmbus: Suspend/resume the vmbus itself for hibernation
Drivers: hv: vmbus: Clean up hv_sock channels by force upon suspend
Drivers: hv: vmbus: Suspend after cleaning up hv_sock and sub channels
Drivers: hv: vmbus: Resume after fixing up old primary channels
drivers/hv/channel_mgmt.c | 161 +++++++++++++++++++++++++---
drivers/hv/connection.c | 8 +-
drivers/hv/hv.c | 66 +++++++-----
drivers/hv/hyperv_vmbus.h | 30 ++++++
drivers/hv/vmbus_drv.c | 265 ++++++++++++++++++++++++++++++++++++++++++++++
include/linux/hyperv.h | 16 ++-
6 files changed, 497 insertions(+), 49 deletions(-)
--
1.8.3.1
From: Dexuan Cui <decui@microsoft.com> Date: 2019-09-05 23:01:21
Break out synic enable and disable operations into separate
hv_synic_disable_regs() and hv_synic_enable_regs() functions for use by a
later patch to support hibernation.
There is no functional change except the unnecessary check
"if (sctrl.enable != 1) return -EFAULT;" which is removed, because when
we're in hv_synic_cleanup(), we're absolutely sure sctrl.enable must be 1.
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Reviewed-by: Michael Kelley <redacted>
---
drivers/hv/hv.c | 66 ++++++++++++++++++++++++++---------------------
drivers/hv/hyperv_vmbus.h | 2 ++
2 files changed, 39 insertions(+), 29 deletions(-)
@@ -196,6 +196,11 @@ int hv_synic_init(unsigned int cpu)sctrl.enable=1;hv_set_synic_state(sctrl.as_uint64);+}++inthv_synic_init(unsignedintcpu)+{+hv_synic_enable_regs(cpu);hv_stimer_init(cpu);
@@ -205,20 +210,45 @@ int hv_synic_init(unsigned int cpu)/**hv_synic_cleanup-Cleanuproutineforhv_synic_init().*/-inthv_synic_cleanup(unsignedintcpu)+voidhv_synic_disable_regs(unsignedintcpu){unionhv_synic_sintshared_sint;unionhv_synic_simpsimp;unionhv_synic_siefpsiefp;unionhv_synic_scontrolsctrl;++hv_get_synint_state(VMBUS_MESSAGE_SINT,shared_sint.as_uint64);++shared_sint.masked=1;++/* Need to correctly cleanup in the case of SMP!!! */+/* Disable the interrupt */+hv_set_synint_state(VMBUS_MESSAGE_SINT,shared_sint.as_uint64);++hv_get_simp(simp.as_uint64);+simp.simp_enabled=0;+simp.base_simp_gpa=0;++hv_set_simp(simp.as_uint64);++hv_get_siefp(siefp.as_uint64);+siefp.siefp_enabled=0;+siefp.base_siefp_gpa=0;++hv_set_siefp(siefp.as_uint64);++/* Disable the global synic bit */+hv_get_synic_state(sctrl.as_uint64);+sctrl.enable=0;+hv_set_synic_state(sctrl.as_uint64);+}++inthv_synic_cleanup(unsignedintcpu)+{structvmbus_channel*channel,*sc;boolchannel_found=false;unsignedlongflags;-hv_get_synic_state(sctrl.as_uint64);-if(sctrl.enable!=1)-return-EFAULT;-/**SearchforchannelswhichareboundtotheCPUwe'reaboutto*cleanup.Incasewefindoneandvmbusisstillconnectedweneedto
@@ -249,29 +279,7 @@ int hv_synic_cleanup(unsigned int cpu)hv_stimer_cleanup(cpu);-hv_get_synint_state(VMBUS_MESSAGE_SINT,shared_sint.as_uint64);--shared_sint.masked=1;--/* Need to correctly cleanup in the case of SMP!!! */-/* Disable the interrupt */-hv_set_synint_state(VMBUS_MESSAGE_SINT,shared_sint.as_uint64);--hv_get_simp(simp.as_uint64);-simp.simp_enabled=0;-simp.base_simp_gpa=0;--hv_set_simp(simp.as_uint64);--hv_get_siefp(siefp.as_uint64);-siefp.siefp_enabled=0;-siefp.base_siefp_gpa=0;--hv_set_siefp(siefp.as_uint64);--/* Disable the global synic bit */-sctrl.enable=0;-hv_set_synic_state(sctrl.as_uint64);+hv_synic_disable_regs(cpu);return0;}
From: Dexuan Cui <decui@microsoft.com> Date: 2019-09-05 23:01:24
This is needed when we resume the old kernel from the "current" kernel.
Note: when hv_synic_suspend() and hv_synic_resume() run, all the
non-boot CPUs have been offlined, and interrupts are disabled on CPU0.
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Reviewed-by: Michael Kelley <redacted>
---
drivers/hv/vmbus_drv.c | 46 ++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 46 insertions(+)
@@ -2086,6 +2087,47 @@ static void hv_crash_handler(struct pt_regs *regs)hyperv_cleanup();};+staticinthv_synic_suspend(void)+{+/*+*Whenwereachhere,allthenon-bootCPUshavebeenofflined,and+*thestimersonthemhavebeenunboundinhv_synic_cleanup()->+*hv_stimer_cleanup()->clockevents_unbind_device().+*+*hv_synic_suspend()onlyrunsonCPU0withinterruptsdisabled.Here+*wedonotunbindthestimeronCPU0because:1)it'sunnecessary+*becausetheinterruptsremaindisabledbetweensyscore_suspend()+*andsyscore_resume():seecreate_image()andresume_target_kernel();+*2)thestimeronCPU0isautomaticallydisabledlaterby+*syscore_suspend()->timekeeping_suspend()->tick_suspend()->...+*->clockevents_shutdown()->...->hv_ce_shutdown();3)awarning+*wouldbetriggeredifwecallclockevents_unbind_device(),which+*maysleep,inaninterrupts-disabledcontext.So,weintentionally+*don'tcallhv_stimer_cleanup(0)here.+*/++hv_synic_disable_regs(0);++return0;+}++staticvoidhv_synic_resume(void)+{+hv_synic_enable_regs(0);++/*+*Note:wedon'tneedtocallhv_stimer_init(0),becausethetimer+*onCPU0isnotunboundinhv_synic_suspend(),andthetimeris+*automaticallyre-enabledintimekeeping_resume().+*/+}++/* The callbacks run only on CPU0, with irqs_disabled. */+staticstructsyscore_opshv_synic_syscore_ops={+.suspend=hv_synic_suspend,+.resume=hv_synic_resume,+};+staticint__inithv_acpi_init(void){intret,t;
@@ -2116,6 +2158,8 @@ static int __init hv_acpi_init(void)hv_setup_kexec_handler(hv_kexec_handler);hv_setup_crash_handler(hv_crash_handler);+register_syscore_ops(&hv_synic_syscore_ops);+return0;cleanup:
@@ -911,6 +911,43 @@ static void vmbus_shutdown(struct device *child_device)drv->shutdown(dev);}+/*+*vmbus_suspend-Suspendavmbusdevice+*/+staticintvmbus_suspend(structdevice*child_device)+{+structhv_driver*drv;+structhv_device*dev=device_to_hv_device(child_device);++/* The device may not be attached yet */+if(!child_device->driver)+return0;++drv=drv_to_hv_drv(child_device->driver);+if(!drv->suspend)+return-EOPNOTSUPP;++returndrv->suspend(dev);+}++/*+*vmbus_resume-Resumeavmbusdevice+*/+staticintvmbus_resume(structdevice*child_device)+{+structhv_driver*drv;+structhv_device*dev=device_to_hv_device(child_device);++/* The device may not be attached yet */+if(!child_device->driver)+return0;++drv=drv_to_hv_drv(child_device->driver);+if(!drv->resume)+return-EOPNOTSUPP;++returndrv->resume(dev);+}/**vmbus_device_release-Finalcallbackreleaseofthevmbuschilddevice
@@ -926,6 +963,14 @@ static void vmbus_device_release(struct device *device)kfree(hv_dev);}+/*+*Note:wemustuseSET_NOIRQ_SYSTEM_SLEEP_PM_OPSratherthan+*SET_SYSTEM_SLEEP_PM_OPS:seethecommentbeforevmbus_bus_pm.+*/+staticconststructdev_pm_opsvmbus_pm={+SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(vmbus_suspend,vmbus_resume)+};+/* The one and only one */staticstructbus_typehv_bus={.name="vmbus",
From: Dexuan Cui <decui@microsoft.com> Date: 2019-09-05 23:01:32
Before Linux enters hibernation, it sends the CHANNELMSG_UNLOAD message to
the host so all the offers are gone. After hibernation, Linux needs to
re-negotiate with the host using the same vmbus protocol version (which
was in use before hibernation), and ask the host to re-offer the vmbus
devices.
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Reviewed-by: Michael Kelley <redacted>
---
drivers/hv/connection.c | 3 +--
drivers/hv/hyperv_vmbus.h | 2 ++
drivers/hv/vmbus_drv.c | 59 +++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 62 insertions(+), 2 deletions(-)
@@ -2089,6 +2089,51 @@ static int vmbus_acpi_add(struct acpi_device *device)returnret_val;}+staticintvmbus_bus_suspend(structdevice*dev)+{+vmbus_initiate_unload(false);++vmbus_connection.conn_state=DISCONNECTED;++return0;+}++staticintvmbus_bus_resume(structdevice*dev)+{+structvmbus_channel_msginfo*msginfo;+size_tmsgsize;+intret;++/*+*Weonlyusethe'vmbus_proto_version',whichwasinusebefore+*hibernation,tore-negotiatewiththehost.+*/+if(vmbus_proto_version==VERSION_INVAL||+vmbus_proto_version==0){+pr_err("Invalid proto version = 0x%x\n",vmbus_proto_version);+return-EINVAL;+}++msgsize=sizeof(*msginfo)++sizeof(structvmbus_channel_initiate_contact);++msginfo=kzalloc(msgsize,GFP_KERNEL);++if(msginfo==NULL)+return-ENOMEM;++ret=vmbus_negotiate_version(msginfo,vmbus_proto_version);++kfree(msginfo);++if(ret!=0)+returnret;++vmbus_request_offers();++return0;+}+staticconststructacpi_device_idvmbus_acpi_device_ids[]={{"VMBUS",0},{"VMBus",0},
@@ -2096,6 +2141,19 @@ static int vmbus_acpi_add(struct acpi_device *device)};MODULE_DEVICE_TABLE(acpi,vmbus_acpi_device_ids);+/*+*Note:wemustuseSET_NOIRQ_SYSTEM_SLEEP_PM_OPSratherthan+*SET_SYSTEM_SLEEP_PM_OPS,otherwiseNICSR-IOVcannotwork,becausethe+*"pci_dev_pm_ops"usesthe"noirq"callbacks:intheresumepath,the+*pci"noirq"restorecallbackrunsbefore"non-noirq"callbacks(see+*resume_target_kernel()->dpm_resume_start(),andhibernation_restore()->+*dpm_resume_end()).Thismeansvmbus_bus_resume()andthepci-hyperv's+*resumecallbackmustalsorunviathe"noirq"callbacks.+*/+staticconststructdev_pm_opsvmbus_bus_pm={+SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(vmbus_bus_suspend,vmbus_bus_resume)+};+staticstructacpi_drivervmbus_acpi_driver={.name="vmbus",.ids=vmbus_acpi_device_ids,
@@ -2103,6 +2161,7 @@ static int vmbus_acpi_add(struct acpi_device *device).add=vmbus_acpi_add,.remove=vmbus_acpi_remove,},+.drv.pm=&vmbus_bus_pm,};staticvoidhv_kexec_handler(void)
From: Dexuan Cui <decui@microsoft.com> Date: 2019-09-05 23:01:35
Before suspend, Linux must make sure all the hv_sock channels have been
properly cleaned up, because a hv_sock connection can not persist across
hibernation, and the user-space app must be properly notified of the
state change of the connection.
Before suspend, Linux also must make sure all the sub-channels have been
destroyed, i.e. the related channel structs of the sub-channels must be
properly removed, otherwise they would cause a conflict when the
sub-channels are recreated upon resume.
Add a counter to track such channels, and vmbus_bus_suspend() should wait
for the counter to drop to zero.
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Reviewed-by: Michael Kelley <redacted>
---
drivers/hv/channel_mgmt.c | 26 ++++++++++++++++++++++++++
drivers/hv/connection.c | 3 +++
drivers/hv/hyperv_vmbus.h | 12 ++++++++++++
drivers/hv/vmbus_drv.c | 44 +++++++++++++++++++++++++++++++++++++++++++-
4 files changed, 84 insertions(+), 1 deletion(-)
@@ -545,6 +545,10 @@ static void vmbus_process_offer(struct vmbus_channel *newchannel)mutex_lock(&vmbus_connection.channel_mutex);+/* Remember the channels that should be cleaned up upon suspend. */+if(is_hvsock_channel(newchannel)||is_sub_channel(newchannel))+atomic_inc(&vmbus_connection.nr_chan_close_on_suspend);+/**Nowthatwehaveacquiredthechannel_mutex,*wecanreleasethepotentiallyracingrescindthread.
@@ -1050,6 +1071,11 @@ static void vmbus_onoffer_rescind(struct vmbus_channel_message_header *hdr)}mutex_unlock(&vmbus_connection.channel_mutex);}++/* The "channel" may have been freed. Do not access it any longer. */++if(clean_up_chan_for_suspend)+check_ready_for_suspend_event();}voidvmbus_hvsock_device_unregister(structvmbus_channel*channel)
@@ -2127,7 +2127,8 @@ static int vmbus_acpi_add(struct acpi_device *device)staticintvmbus_bus_suspend(structdevice*dev){-structvmbus_channel*channel;+structvmbus_channel*channel,*sc;+unsignedlongflags;while(atomic_read(&vmbus_connection.offer_in_progress)!=0){/*
@@ -2146,6 +2147,44 @@ static int vmbus_bus_suspend(struct device *dev)}mutex_unlock(&vmbus_connection.channel_mutex);+/*+*Waituntilallthesub-channelsandhv_sockchannelshavebeen+*cleanedup.Sub-channelsshouldbedestroyeduponsuspend,otherwise+*theywouldconflictwiththenewsub-channelsthatwillbecreated+*intheresumepath.hv_sockchannelsshouldalsobedestroyed,but+*ahv_sockchannelofanestablishedhv_sockconnectioncannotbe+*reallydestroyedsinceitmaystillbereferencedbytheuserspace+*application,sowejustforcethehv_sockchanneltoberescinded+*byvmbus_force_channel_rescinded(),andtheuserspaceapplication+*willthoroughlydestroythechannelafterhibernation.+*+*Note:thecounternr_chan_close_on_suspendmaynevergoabove0if+*theVMhasnosub-channelandhv_sockchannel,e.g.a1-vCPUVM.+*/+if(atomic_read(&vmbus_connection.nr_chan_close_on_suspend)>0)+wait_for_completion(&vmbus_connection.ready_for_suspend_event);++mutex_lock(&vmbus_connection.channel_mutex);++list_for_each_entry(channel,&vmbus_connection.chn_list,listentry){+if(is_hvsock_channel(channel)){+if(!channel->rescind){+pr_err("hv_sock channel not rescinded!\n");+WARN_ON_ONCE(1);+}+continue;+}++spin_lock_irqsave(&channel->lock,flags);+list_for_each_entry(sc,&channel->sc_list,sc_list){+pr_err("Sub-channel not deleted!\n");+WARN_ON_ONCE(1);+}+spin_unlock_irqrestore(&channel->lock,flags);+}++mutex_unlock(&vmbus_connection.channel_mutex);+vmbus_initiate_unload(false);vmbus_connection.conn_state=DISCONNECTED;
@@ -2186,6 +2225,9 @@ static int vmbus_bus_resume(struct device *dev)vmbus_request_offers();+/* Reset the event for the next suspend. */+reinit_completion(&vmbus_connection.ready_for_suspend_event);+return0;}
From: Dexuan Cui <decui@microsoft.com> Date: 2019-09-05 23:01:38
When the host re-offers the primary channels upon resume, the host only
guarantees the Instance GUID doesn't change, so vmbus_bus_suspend()
should invalidate channel->offermsg.child_relid and figure out the
number of primary channels that need to be fixed up upon resume.
Upon resume, vmbus_onoffer() finds the old channel structs, and maps
the new offers to the old channels, and fixes up the old structs,
and finally the resume callbacks of the VSC drivers will re-open
the channels.
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Reviewed-by: Michael Kelley <redacted>
---
drivers/hv/channel_mgmt.c | 85 ++++++++++++++++++++++++++++++++++++-----------
drivers/hv/connection.c | 2 ++
drivers/hv/hyperv_vmbus.h | 14 ++++++++
drivers/hv/vmbus_drv.c | 17 ++++++++++
include/linux/hyperv.h | 3 ++
5 files changed, 101 insertions(+), 20 deletions(-)
@@ -2164,9 +2164,17 @@ static int vmbus_bus_suspend(struct device *dev)if(atomic_read(&vmbus_connection.nr_chan_close_on_suspend)>0)wait_for_completion(&vmbus_connection.ready_for_suspend_event);+WARN_ON(atomic_read(&vmbus_connection.nr_chan_fixup_on_resume)!=0);+mutex_lock(&vmbus_connection.channel_mutex);list_for_each_entry(channel,&vmbus_connection.chn_list,listentry){+/*+*Invalidatethefield.Uponresume,vmbus_onoffer()willfix+*upthefield,andtheotherfields(ifnecessary).+*/+channel->offermsg.child_relid=INVALID_RELID;+if(is_hvsock_channel(channel)){if(!channel->rescind){pr_err("hv_sock channel not rescinded!\n");
@@ -2181,6 +2189,8 @@ static int vmbus_bus_suspend(struct device *dev)WARN_ON_ONCE(1);}spin_unlock_irqrestore(&channel->lock,flags);++atomic_inc(&vmbus_connection.nr_chan_fixup_on_resume);}mutex_unlock(&vmbus_connection.channel_mutex);
@@ -2189,6 +2199,9 @@ static int vmbus_bus_suspend(struct device *dev)vmbus_connection.conn_state=DISCONNECTED;+/* Reset the event for the next resume. */+reinit_completion(&vmbus_connection.ready_for_resume_event);+return0;}
@@ -2223,8 +2236,12 @@ static int vmbus_bus_resume(struct device *dev)if(ret!=0)returnret;+WARN_ON(atomic_read(&vmbus_connection.nr_chan_fixup_on_resume)==0);+vmbus_request_offers();+wait_for_completion(&vmbus_connection.ready_for_resume_event);+/* Reset the event for the next suspend. */reinit_completion(&vmbus_connection.ready_for_suspend_event);
From: Dexuan Cui <decui@microsoft.com> Date: 2019-09-05 23:01:42
When the VM resumes, the host re-sends the offers. We should not add the
offers to the global vmbus_connection.chn_list again.
This patch assumes the RELIDs of the channels don't change across
hibernation. Actually this is not always true, especially in the case of
NIC SR-IOV the VF vmbus device's RELID sometimes can change. A later patch
will address this issue by mapping the new offers to the old channels and
fixing up the old channels, if necessary.
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Reviewed-by: Michael Kelley <redacted>
---
drivers/hv/channel_mgmt.c | 58 ++++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 57 insertions(+), 1 deletion(-)
From: Dexuan Cui <decui@microsoft.com> Date: 2019-09-05 23:01:44
Fake RESCIND_CHANNEL messages to clean up hv_sock channels by force for
hibernation. There is no better method to clean up the channels since
some of the channels may still be referenced by the userspace apps when
hibernation is triggered: in this case, with this patch, the "rescind"
fields of the channels are set, and the apps will thoroughly destroy
the channels after hibernation.
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Reviewed-by: Michael Kelley <redacted>
---
drivers/hv/vmbus_drv.c | 55 ++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 55 insertions(+)
@@ -1069,6 +1070,41 @@ void vmbus_on_msg_dpc(unsigned long data)vmbus_signal_eom(msg,message_type);}+/*+*FakeRESCIND_CHANNELmessagestocleanuphv_sockchannelsbyforcefor+*hibernation,becausehv_sockconnectionscannotpersistacrosshibernation.+*/+staticvoidvmbus_force_channel_rescinded(structvmbus_channel*channel)+{+structonmessage_work_context*ctx;+structvmbus_channel_rescind_offer*rescind;++WARN_ON(!is_hvsock_channel(channel));++/*+*sizeof(*ctx)issmallandtheallocationshouldreallynotfail,+*otherwisethestateofthehv_sockconnectionsendsupinlimbo.+*/+ctx=kzalloc(sizeof(*ctx),GFP_KERNEL|__GFP_NOFAIL);++/*+*Sofar,thesearenotreallyusedbyLinux.Justsetthemtothe+*reasonablevaluesconformingtothedefinitionsofthefields.+*/+ctx->msg.header.message_type=1;+ctx->msg.header.payload_size=sizeof(*rescind);++/* These values are actually used by Linux. */+rescind=(structvmbus_channel_rescind_offer*)ctx->msg.u.payload;+rescind->header.msgtype=CHANNELMSG_RESCIND_CHANNELOFFER;+rescind->child_relid=channel->offermsg.child_relid;++INIT_WORK(&ctx->work,vmbus_onmessage_work);++queue_work_on(vmbus_connection.connect_cpu,+vmbus_connection.work_queue,+&ctx->work);+}/**Directcallbackforchannelsusingotherdeferredprocessing
@@ -2091,6 +2127,25 @@ static int vmbus_acpi_add(struct acpi_device *device)staticintvmbus_bus_suspend(structdevice*dev){+structvmbus_channel*channel;++while(atomic_read(&vmbus_connection.offer_in_progress)!=0){+/*+*Wewaithereuntilthecompletionofanychannel+*offersthatarecurrentlyinprogress.+*/+msleep(1);+}++mutex_lock(&vmbus_connection.channel_mutex);+list_for_each_entry(channel,&vmbus_connection.chn_list,listentry){+if(!is_hvsock_channel(channel))+continue;++vmbus_force_channel_rescinded(channel);+}+mutex_unlock(&vmbus_connection.channel_mutex);+vmbus_initiate_unload(false);vmbus_connection.conn_state=DISCONNECTED;
From: Dexuan Cui <decui@microsoft.com> Date: 2019-09-05 23:01:51
The existing method of telling if a channel is sub-channel in
vmbus_process_offer() is cumbersome. This new simple helper function
is preferred in future.
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Reviewed-by: Michael Kelley <redacted>
---
include/linux/hyperv.h | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
On Thu, Sep 05, 2019 at 11:01:14PM +0000, Dexuan Cui wrote:
This patchset (consisting of 9 patches) was part of the v4 patchset (consisting
of 12 patches):
https://lkml.org/lkml/2019/9/2/894
The other 3 patches in v4 are posted in another patchset, which will go
through the tip.git tree.
All the 9 patches here are now rebased to the hyperv tree's hyperv-next branch:
https://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux.git/log/?h=hyperv-next
, and all the 9 patches have Michael Kelley's Signed-off-by's.
Please review.
Given that these two series depend on each other, I'd much prefer for
them to go through one tree.
But, I may be wrong, and I'm going to see if a scenario such as this
make sense. I've queued this one to the hyperv-next, but I'll wait for
the x86 folks to send their pull request to Linus first before I do it
for these patches.
Usually cases such as these are the exception, but for Hyper-V it seems
to be the norm, so I'm curious to see how this will unfold.
--
Thanks,
Sasha
From: Dexuan Cui <decui@microsoft.com> Date: 2019-09-06 22:45:57
From: Sasha Levin <sashal@kernel.org>
Sent: Friday, September 6, 2019 1:03 PM
On Thu, Sep 05, 2019 at 11:01:14PM +0000, Dexuan Cui wrote:
quoted
This patchset (consisting of 9 patches) was part of the v4 patchset (consisting
of 12 patches):
The other 3 patches in v4 are posted in another patchset, which will go
through the tip.git tree.
All the 9 patches here are now rebased to the hyperv tree's hyperv-next
branch, and all the 9 patches have Michael Kelley's Signed-off-by's.
quoted
Please review.
Given that these two series depend on each other, I'd much prefer for
them to go through one tree.
Hi Sasha,
Yeah, that would be ideal. The problem here is: the other patchset conflicts
with the existing patches in the tip.git tree's timers/core branch, so IMO
the 3 patches have to go through the tip tree:
[PATCH v5 1/3] x86/hyper-v: Suspend/resume the hypercall page for hibernation
[PATCH v5 2/3] x86/hyper-v: Implement hv_is_hibernation_supported()
[PATCH v5 3/3] clocksource/drivers: Suspend/resume Hyper-V clocksource for hibernation
But, I may be wrong, and I'm going to see if a scenario such as this
make sense. I've queued this one to the hyperv-next, but I'll wait for
the x86 folks to send their pull request to Linus first before I do it
for these patches.
Actually IMHO you don't need to wait, because there is not a build
dependency, so either patchset can go into the Linus's tree first.
The 2 patchsets are just the first step to make hibernation work for Linux VM
running on Hyper-V. Next I'm going to post some high-level VSC patches for
hv_balloon, hv_utils, hv_netvsc, hid_hyperv, hv_storvsc, hyperv_keyboard,
hyperv_fb,etc. All of these should go through the hyperv tree, since they're
pure hyper-v changes, and they depend on this 9-patch patchset. I'll make
a note in every patch so the subsystem maintainers will be aware and ack it.
Among the VSC patches, the hv_balloon patch does depend on the 2nd patch:
[PATCH v5 2/3] x86/hyper-v: Implement hv_is_hibernation_supported().
I think I'll wait for the aforementioned 2 patchsets to be in first, before posting
the hv_balloon patch.
Usually cases such as these are the exception, but for Hyper-V it seems
to be the norm, so I'm curious to see how this will unfold.
Thanks,
Sasha
Thanks for taking care all the patches!
Thanks,
-- Dexuan
On Fri, Sep 06, 2019 at 10:45:31PM +0000, Dexuan Cui wrote:
quoted
From: Sasha Levin <sashal@kernel.org>
Sent: Friday, September 6, 2019 1:03 PM
On Thu, Sep 05, 2019 at 11:01:14PM +0000, Dexuan Cui wrote:
quoted
This patchset (consisting of 9 patches) was part of the v4 patchset (consisting
of 12 patches):
The other 3 patches in v4 are posted in another patchset, which will go
through the tip.git tree.
All the 9 patches here are now rebased to the hyperv tree's hyperv-next
branch, and all the 9 patches have Michael Kelley's Signed-off-by's.
quoted
Please review.
Given that these two series depend on each other, I'd much prefer for
them to go through one tree.
Hi Sasha,
Yeah, that would be ideal. The problem here is: the other patchset conflicts
with the existing patches in the tip.git tree's timers/core branch, so IMO
the 3 patches have to go through the tip tree:
[PATCH v5 1/3] x86/hyper-v: Suspend/resume the hypercall page for hibernation
[PATCH v5 2/3] x86/hyper-v: Implement hv_is_hibernation_supported()
[PATCH v5 3/3] clocksource/drivers: Suspend/resume Hyper-V clocksource for hibernation
quoted
But, I may be wrong, and I'm going to see if a scenario such as this
make sense. I've queued this one to the hyperv-next, but I'll wait for
the x86 folks to send their pull request to Linus first before I do it
for these patches.
Actually IMHO you don't need to wait, because there is not a build
dependency, so either patchset can go into the Linus's tree first.
It'll build, sure. But did anyone actually test one without the other?
What happens if Thomas doesn't send his batch at all during the merge
window?
--
Thanks,
Sasha
From: Dexuan Cui <decui@microsoft.com> Date: 2019-09-08 16:34:07
From: Sasha Levin <sashal@kernel.org>
Sent: Sunday, September 8, 2019 5:13 AM
On Fri, Sep 06, 2019 at 10:45:31PM +0000, Dexuan Cui wrote:
quoted
quoted
From: Sasha Levin <sashal@kernel.org>
Sent: Friday, September 6, 2019 1:03 PM
On Thu, Sep 05, 2019 at 11:01:14PM +0000, Dexuan Cui wrote:
quoted
This patchset (consisting of 9 patches) was part of the v4 patchset
(consisting
quoted
quoted
quoted
of 12 patches):
The other 3 patches in v4 are posted in another patchset, which will go
through the tip.git tree.
All the 9 patches here are now rebased to the hyperv tree's hyperv-next
branch, and all the 9 patches have Michael Kelley's Signed-off-by's.
quoted
Please review.
Given that these two series depend on each other, I'd much prefer for
them to go through one tree.
Hi Sasha,
Yeah, that would be ideal. The problem here is: the other patchset conflicts
with the existing patches in the tip.git tree's timers/core branch, so IMO
the 3 patches have to go through the tip tree:
[PATCH v5 1/3] x86/hyper-v: Suspend/resume the hypercall page for
But, I may be wrong, and I'm going to see if a scenario such as this
make sense. I've queued this one to the hyperv-next, but I'll wait for
the x86 folks to send their pull request to Linus first before I do it
for these patches.
Actually IMHO you don't need to wait, because there is not a build
dependency, so either patchset can go into the Linus's tree first.
It'll build, sure. But did anyone actually test one without the other?
Nobody tested this.
The fact is: even if we have the 2 patchsets, hibernation still can not work
for Linux VM on Hyper-V, because we also need the high level driver
changes to hv_netvsc, hv_storvsc, etc. I'm going to send out these
patches soon.
What happens if Thomas doesn't send his batch at all during the merge
window?
Sasha
We need all the patches together to make hibernation work.
I just meant that the 2 patchsets don't have to go into Linus's tree in
a special order, as there is no build issue.
Thanks,
-- Dexuan