Date: Wed, 3 Feb 2016 23:17:40 +0000 From: Jac Backus <j.backus@bugworks.com> To: 'Dexuan Cui' <decui@microsoft.com>, "Sephe Qiao (Wicresoft)" <v-yanqia@microsoft.com>, Kylie Liang <kyliel@microsoft.com>, "'freebsd-virtualization@freebsd.org'" <freebsd-virtualization@freebsd.org>, BSD Integration Components for Hyper-V <bsdic@microsoft.com> Subject: RE: Hyper-V networking: problem after upgrade to 10.2 Message-ID: <53238096372f4362b436382a430bde57@ORTELIUS.internal.bugworks.com> In-Reply-To: <17b639f383df4f42b1e050f6e40d1ad2@HKXPR3004MB0088.064d.mgd.msft.net> References: <cdb46889a0164856987da43537a104de@ORTELIUS.internal.bugworks.com> <8572369fcc3b408891fc1a5a7d11e892@SG2PR3002MB0107.064d.mgd.msft.net> <bcca15b9c5cd4e0db3d80b40bde7405a@HKXPR3004MB0088.064d.mgd.msft.net> <1430812ff38c4e08a4b91ea25fdb5a7b@HKXPR3004MB0088.064d.mgd.msft.net> <1fdbb9b939c54e31ac00329f61bf6f41@ORTELIUS.internal.bugworks.com> <2323532a95934cdfae0142a9d6f88fd8@SG2PR3004MB0090.064d.mgd.msft.net> <2b22a9544c6c4ff3b017133a346e75e2@SG2PR3004MB0090.064d.mgd.msft.net> <7df41cc958ee408297487d4ffbb91903@HKXPR3004MB0088.064d.mgd.msft.net> <4e85ad234a0b4618ae5862fbcd266e3d@ORTELIUS.internal.bugworks.com> <0f761afc10864ad3aeb89ee7c9b6e8ac@HKXPR3004MB0088.064d.mgd.msft.net> <d1f0f7492a8d4bcca6acc4e7062e7855@ORTELIUS.internal.bugworks.com> <4105829efb1e4b3a91bc17f7fbdf8ac8@HKXPR3004MB0088.064d.mgd.msft.net> <0ce04bf413204478b1e7cc71ac28ecac@ORTELIUS.internal.bugworks.com> <1aba0d827b9041b79b85a09cf70e52b1@HKXPR3004MB0088.064d.mgd.msft.net> <dab71654578744c99e0ca2f800df7929@ORTELIUS.internal.bugworks.com> <d4e895d3f7324773bbe3459bc6522dd3@HKXPR3004MB0088.064d.mgd.msft.net> <e23579410d8240fd92e21cbd5bec98ac@ORTELIUS.internal.bugworks.com> <4a98b41221ed4c3b84a8c733aa23f24d@HKXPR3004MB0088.064d.mgd.msft.net> <d9312cab2a514d2790d4ad6e452b1c05@ORTELIUS.internal.bugworks.com> <da559e9f67414d6baa0a57267a64d837@HKXPR3004MB0088.064d.mgd.msft.net> <5a09277abe094f5989fb145c12a511df@ORTELIUS.internal.bugworks.com> <17b639f383df4f42b1e050f6e40d1ad2@HKXPR3004MB0088.064d.mgd.msft.net>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] Hello Dexuan, The first patch gives no messages. When trying the second: 112 # patch -sp1 < 1e469c559048fe6ec3641da3bb21ab87215c6506.patch 1 out of 7 hunks failed--saving rejects to sys/dev/hyperv/vmbus/hv_channel_mgmt.c.rej Attached you find the patched file (as a session log). With kind regards, Jac Van: Dexuan Cui [mailto:decui@microsoft.com] Verzonden: woensdag 3 februari 2016 10:05 Aan: Jac Backus; Sephe Qiao (Wicresoft); Kylie Liang; 'freebsd-virtualization@freebsd.org'; BSD Integration Components for Hyper-V Onderwerp: RE: Hyper-V networking: problem after upgrade to 10.2 Thanks for the confirmation, Jac. I might be wrong with 10.1 - it may not have the issue. In 10.2 we made a lot of changes and I think the race condition was introduced. To test the 2 patches, you can do something like cd /usr/src (supposing the 10.2 kernel code is in the sys/ sub-directory) wget https://github.com/freebsd/freebsd/commit/850d0994e48b0ef68d33875e26326d44931fcf1e.patch patch -sp1 < 850d0994e48b0ef68d33875e26326d44931fcf1e.patch wget https://github.com/freebsd/freebsd/commit/1e469c559048fe6ec3641da3bb21ab87215c6506.patch patch -sp1 < 1e469c559048fe6ec3641da3bb21ab87215c6506.patch make buildkernel KERNCONF=GENERIC -j8 make installkernel reboot You may get a small issue when applying the second patch as I did: 1 out of 8 hunks failed--saving rejects to sys/dev/hyperv/vmbus/hv_channel_mgmt.c.rej You can fix this by checking the .patch/.c files and manually editing the .c file. Thanks, -- Dexuan From: Jac Backus [mailto:j.backus@bugworks.com] Sent: Wednesday, February 3, 2016 16:10 To: Dexuan Cui <decui@microsoft.com<mailto:decui@microsoft.com>>; Sephe Qiao (Wicresoft) <v-yanqia@microsoft.com<mailto:v-yanqia@microsoft.com>>; Kylie Liang <kyliel@microsoft.com<mailto:kyliel@microsoft.com>>; 'freebsd-virtualization@freebsd.org' <freebsd-virtualization@freebsd.org<mailto:freebsd-virtualization@freebsd.org>>; BSD Integration Components for Hyper-V <bsdic@microsoft.com<mailto:bsdic@microsoft.com>> Subject: RE: Hyper-V networking: problem after upgrade to 10.2 Good day Dexuan, I think it is. I should like to test. Are there some instructions for patching the 10.2 kernel source? You mention 10.1 too, but I never had the problem with 10.1. Thanks very for your kind help! With kind regards, Jac Van: Dexuan Cui [mailto:decui@microsoft.com] Verzonden: woensdag 3 februari 2016 1:50 Aan: Jac Backus; Sephe Qiao (Wicresoft); Kylie Liang; 'freebsd-virtualization@freebsd.org'; BSD Integration Components for Hyper-V Onderwerp: RE: Hyper-V networking: problem after upgrade to 10.2 Jac, really great news! So, can I think the whole issue in your side is caused by Bug 205156? The fix to the bug has been in the 10/stable branch and should be in the coming 10.3. For 10.1 and 10.2 , I'm afraid you'll have to manually apply the patches and build a new kernel. BTW, the bug is actually a race condition when the netvsc driver registers multiple NIC devices, so sometimes we can easily repro the issue and sometimes we can't. Thanks, -- Dexuan From: Jac Backus [mailto:j.backus@bugworks.com] Sent: Wednesday, February 3, 2016 2:28 To: Dexuan Cui <decui@microsoft.com<mailto:decui@microsoft.com>>; Sephe Qiao (Wicresoft) <v-yanqia@microsoft.com<mailto:v-yanqia@microsoft.com>>; Kylie Liang <kyliel@microsoft.com<mailto:kyliel@microsoft.com>>; 'freebsd-virtualization@freebsd.org' <freebsd-virtualization@freebsd.org<mailto:freebsd-virtualization@freebsd.org>>; BSD Integration Components for Hyper-V <bsdic@microsoft.com<mailto:bsdic@microsoft.com>> Subject: RE: Hyper-V networking: problem after upgrade to 10.2 Dexuan, you are briljant! That is the problem: Hn0 has the mac address of hn1, hn1 of hn2 and hn2 of hn0. So they have shifted one position to the left. With kind regards, Jac Van: Dexuan Cui [mailto:decui@microsoft.com] Verzonden: maandag 1 februari 2016 10:41 Aan: Jac Backus; Sephe Qiao (Wicresoft); Kylie Liang; 'freebsd-virtualization@freebsd.org'; BSD Integration Components for Hyper-V Onderwerp: RE: Hyper-V networking: problem after upgrade to 10.2 Hmm, it's really strange... what's the difference between your existing 10.1 VM and a fresh 10.1 VM... :( BTW, please check if you are seeing this bug (it looks in your side the network can stop working after a VM reboot): Bug 205156 - [Hyper-V] NICs' (hn0, hn1) MAC addresses can appear in an uncertain way across reboot (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205156<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fbugs.freebsd.org%2fbugzilla%2fshow_bug.cgi%3fid%3d205156&data=01%7c01%7cdecui%40064d.mgd.microsoft.com%7ce1d0508d7e1a475e9c5d08d32bfef518%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=SIv6Bi0qESksmQD3f1UKYUkoV9yGRL1xajG6K1qSdZA%3d>)? Thanks, -- Dexuan From: Jac Backus [mailto:j.backus@bugworks.com] Sent: Monday, February 1, 2016 17:17 To: Dexuan Cui <decui@microsoft.com<mailto:decui@microsoft.com>>; Sephe Qiao (Wicresoft) <v-yanqia@microsoft.com<mailto:v-yanqia@microsoft.com>>; Kylie Liang <kyliel@microsoft.com<mailto:kyliel@microsoft.com>>; 'freebsd-virtualization@freebsd.org' <freebsd-virtualization@freebsd.org<mailto:freebsd-virtualization@freebsd.org>>; BSD Integration Components for Hyper-V <bsdic@microsoft.com<mailto:bsdic@microsoft.com>> Subject: RE: Hyper-V networking: problem after upgrade to 10.2 Good day Dexuan, I did. Unfortunately, no difference. And at the moment the server is running on the 10.2 kernel: uname -a FreeBSD roadrunner.acme.inc 10.2-RELEASE-p9 FreeBSD 10.2-RELEASE-p9 #0: Thu Jan 14 01:32:46 UTC 2016 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC<mailto:root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC> amd64 But there is a big chance, that after a reboot, the network is gone again. I will see if, when it works, it keeps working. I suppose it does. With kind regards, Jac Van: Dexuan Cui [mailto:decui@microsoft.com] Verzonden: maandag 1 februari 2016 3:07 Aan: Jac Backus; Sephe Qiao (Wicresoft); Kylie Liang; 'freebsd-virtualization@freebsd.org'; BSD Integration Components for Hyper-V Onderwerp: RE: Hyper-V networking: problem after upgrade to 10.2 Hi Jac, Good to know this! It looks to me something in the VM or in the host might be causing the issue??? Can you please do another quick test: shut down the "buggy" VM and remove it in Hyper-V Manager (this will keep the .vhdx image) and then re-create the VM with the .vhdx image? Thanks, -- Dexuan From: Jac Backus [mailto:j.backus@bugworks.com] Sent: Sunday, January 31, 2016 23:21 To: Dexuan Cui <decui@microsoft.com<mailto:decui@microsoft.com>>; Sephe Qiao (Wicresoft) <v-yanqia@microsoft.com<mailto:v-yanqia@microsoft.com>>; Kylie Liang <kyliel@microsoft.com<mailto:kyliel@microsoft.com>>; 'freebsd-virtualization@freebsd.org' <freebsd-virtualization@freebsd.org<mailto:freebsd-virtualization@freebsd.org>>; BSD Integration Components for Hyper-V <bsdic@microsoft.com<mailto:bsdic@microsoft.com>> Subject: RE: Hyper-V networking: problem after upgrade to 10.2 Hello Dexuan, I did a fresh install of a 10.1 VM and upgraded it to 10.2. Is looks like it works well. With kind regards, Jac Van: Dexuan Cui [mailto:decui@microsoft.com] Verzonden: zondag 31 januari 2016 7:07 Aan: Jac Backus; Sephe Qiao (Wicresoft); Kylie Liang; 'freebsd-virtualization@freebsd.org'; BSD Integration Components for Hyper-V Onderwerp: RE: Hyper-V networking: problem after upgrade to 10.2 Hi Jac, Good to know the information. Since I can't repro the issue, it's difficult for me to debug it. :( I'm guessing if it would help if you use a permanent ARP entry in the VM ("arp -s hostname ether_addr") for the other end - surely this is only for debug purpose. During the VM boot-up, can you keep pinging the VM from the other host. I mean: it looks the NIC never works since it becomes UP in the VM? BTW, I'm not sure if it's easy for you to do the same test as mine, i.e., do a fresh installation of 10.1 VM and upgrade it to 10.2. @Sephe, any idea? Thanks, -- Dexuan From: Jac Backus [mailto:j.backus@bugworks.com] Sent: Sunday, January 31, 2016 3:42 To: Dexuan Cui <decui@microsoft.com<mailto:decui@microsoft.com>>; Sephe Qiao (Wicresoft) <v-yanqia@microsoft.com<mailto:v-yanqia@microsoft.com>>; Kylie Liang <kyliel@microsoft.com<mailto:kyliel@microsoft.com>>; 'freebsd-virtualization@freebsd.org' <freebsd-virtualization@freebsd.org<mailto:freebsd-virtualization@freebsd.org>>; BSD Integration Components for Hyper-V <bsdic@microsoft.com<mailto:bsdic@microsoft.com>> Subject: RE: Hyper-V networking: problem after upgrade to 10.2 Good day Dexuan, There is something wrong with getting mac addresses for host on the lan, it seems. When I ping the 10.2 server from a host on the net, I see on that host arp requests (Wireshark: who has ... Tell ...) for the 10.2 server. Arp -a on the 10.2 server itself says for the non-server entries ? <address> at (imcomplete) on hn0 expired [ethernet] Tcpdump on the 10.2 server only shows arp requests: ARP, Request who-has ... tell ... Does this help? With kind regards, Jac Van: Dexuan Cui [mailto:decui@microsoft.com] Verzonden: vrijdag 29 januari 2016 9:59 Aan: Jac Backus; Sephe Qiao (Wicresoft); Kylie Liang; 'freebsd-virtualization@freebsd.org'; BSD Integration Components for Hyper-V Onderwerp: RE: Hyper-V networking: problem after upgrade to 10.2 Hmm, it's strange we can't repro. I suppose you can't ping the netgate VM (or machine) 's IP address either? When this happens, can you check the arp table in both sides? Can you please run tcpdump in the VM and in the gateway to diagnose the issue? Thanks, -- Dexuan From: Jac Backus [mailto:j.backus@bugworks.com] Sent: Friday, January 29, 2016 15:36 To: Dexuan Cui <decui@microsoft.com<mailto:decui@microsoft.com>>; Sephe Qiao (Wicresoft) <v-yanqia@microsoft.com<mailto:v-yanqia@microsoft.com>>; Kylie Liang <kyliel@microsoft.com<mailto:kyliel@microsoft.com>>; 'freebsd-virtualization@freebsd.org' <freebsd-virtualization@freebsd.org<mailto:freebsd-virtualization@freebsd.org>>; BSD Integration Components for Hyper-V <bsdic@microsoft.com<mailto:bsdic@microsoft.com>> Subject: RE: Hyper-V networking: problem after upgrade to 10.2 Hello Dexuan, That remarkable. My uname -a is indentical. I can ping local interfaces. Ping to other addresses in local subnet gives: Ping: sendto: Host is down. Ping to other addresses gives: Ping: sendto: No route to host. Routing tables (netstat -rn) for both versions look the same. Is there something I can test? With kind regards, Jac Van: Dexuan Cui [mailto:decui@microsoft.com] Verzonden: vrijdag 29 januari 2016 4:25 Aan: Jac Backus; Sephe Qiao (Wicresoft); Kylie Liang; 'freebsd-virtualization@freebsd.org'; BSD Integration Components for Hyper-V Onderwerp: RE: Hyper-V networking: problem after upgrade to 10.2 Hi Jac, I installed a 10.1 VM with FreeBSD-10.1-RELEASE-amd64-dvd1.iso and upgraded it to 10.2 by running "freebsd-update upgrade -r 10.2-RELEASE". Everything worked just fine. With the new kernel (see the below), ssh and scp still works fine for me. # uname -a FreeBSD bsd101 10.2-RELEASE-p9 FreeBSD 10.2-RELEASE-p9 #0: Thu Jan 14 01:32:46 UTC 2016 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC<mailto:root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC> amd64 What's the specific symptom for "networking does not work anymore" in your side(upgrading from 10.1 to 10.2)? Thanks, -- Dexuan From: Jac Backus [mailto:j.backus@bugworks.com] Sent: Wednesday, January 27, 2016 17:35 To: Dexuan Cui <decui@microsoft.com<mailto:decui@microsoft.com>>; Sephe Qiao (Wicresoft) <v-yanqia@microsoft.com<mailto:v-yanqia@microsoft.com>>; Kylie Liang <kyliel@microsoft.com<mailto:kyliel@microsoft.com>>; 'freebsd-virtualization@freebsd.org' <freebsd-virtualization@freebsd.org<mailto:freebsd-virtualization@freebsd.org>>; BSD Integration Components for Hyper-V <bsdic@microsoft.com<mailto:bsdic@microsoft.com>> Subject: RE: Hyper-V networking: problem after upgrade to 10.2 Hello Dexuan, Unfortunetely, no OACTIVE flag: hn0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=31b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,TSO4,TSO6> With kind regards, Jac Van: Dexuan Cui [mailto:decui@microsoft.com] Verzonden: woensdag 27 januari 2016 4:09 Aan: Sephe Qiao (Wicresoft); Jac Backus; Kylie Liang; 'freebsd-virtualization@freebsd.org'; BSD Integration Components for Hyper-V Onderwerp: RE: Hyper-V networking: problem after upgrade to 10.2 Hi Jac, Please show 'ifconfig -a' when the issue happens (when you upgrade 10.1 from 10.2). We suspect it may be a known OACTIVE issue and "ifconfig -a' can confirm this, the output has the string "OACTIVE". It looks somehow the issue doesn't happen when we use a 10.2 fresh installation. Thanks, -- Dexuan From: Sephe Qiao (Wicresoft) Sent: Wednesday, January 27, 2016 9:13 To: Jac Backus <j.backus@bugworks.com<mailto:j.backus@bugworks.com>>; Dexuan Cui <decui@microsoft.com<mailto:decui@microsoft.com>>; Kylie Liang <kyliel@microsoft.com<mailto:kyliel@microsoft.com>>; 'freebsd-virtualization@freebsd.org' <freebsd-virtualization@freebsd.org<mailto:freebsd-virtualization@freebsd.org>>; BSD Integration Components for Hyper-V <bsdic@microsoft.com<mailto:bsdic@microsoft.com>> Subject: RE: Hyper-V networking: problem after upgrade to 10.2 Oh, please ignore this, I think its solved :) From: Sephe Qiao (Wicresoft) Sent: Wednesday, January 27, 2016 9:10 AM To: Jac Backus <j.backus@bugworks.com<mailto:j.backus@bugworks.com>>; Dexuan Cui <decui@microsoft.com<mailto:decui@microsoft.com>>; Kylie Liang <kyliel@microsoft.com<mailto:kyliel@microsoft.com>>; 'freebsd-virtualization@freebsd.org' <freebsd-virtualization@freebsd.org<mailto:freebsd-virtualization@freebsd.org>>; BSD Integration Components for Hyper-V <bsdic@microsoft.com<mailto:bsdic@microsoft.com>> Subject: RE: Hyper-V networking: problem after upgrade to 10.2 Hi Jac, What's the output of 'ifconfig -a' when this happened? Thanks, sephe From: Jac Backus [mailto:j.backus@bugworks.com] Sent: Tuesday, January 26, 2016 6:37 PM To: Dexuan Cui <decui@microsoft.com<mailto:decui@microsoft.com>>; Kylie Liang <kyliel@microsoft.com<mailto:kyliel@microsoft.com>>; 'freebsd-virtualization@freebsd.org' <freebsd-virtualization@freebsd.org<mailto:freebsd-virtualization@freebsd.org>>; BSD Integration Components for Hyper-V <bsdic@microsoft.com<mailto:bsdic@microsoft.com>> Subject: RE: Hyper-V networking: problem after upgrade to 10.2 Hello Dexuan, It seems, it is not completely correct, although the effect is as if it is not working. Systat -ifstat 1 shows this: [cid:image001.png@01D159DA.65A3A0E0] So something is happening. But I can not reach anything. And the server can not be reached from the lan (hn0) or internet (hn1 and hn2). I get a firewall message in /var/log/messages (first message from 11:18:55): [cid:image002.png@01D159DA.65A3A0E0] But this is just caused by the problem? If I can help with further information, please let me know. Regarding Bug 187006, all interfaces have fixed addresses. With kind regards, Jac -----Oorspronkelijk bericht----- Van: Dexuan Cui [mailto:decui@microsoft.com] Verzonden: dinsdag 26 januari 2016 7:55 Aan: Kylie Liang; Jac Backus; 'freebsd-virtualization@freebsd.org'; BSD Integration Components for Hyper-V Onderwerp: RE: Hyper-V networking: problem after upgrade to 10.2 Hi Jac, BTW, what do you mean by saying "networking does not work anymore" -- can you please check if your issue is the same as Bug 187006 - [hyper-v] dynamic address (dhcp) obtaining doesn't work on HYPER-V OS 2012 R2 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187006<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fbugs.freebsd.org%2fbugzilla%2fshow_bug.cgi%3fid%3d187006&data=01%7c01%7cv-yanqia%40064d.mgd.microsoft.com%7cef82474449e745da88c908d3263e7e48%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=1IyQb3x7ecm%2f6uESQmVAAyAyOQr4ZMJ3Fkawp93dZgQ%3d>; ? Thanks, -- Dexuan > -----Original Message----- > From: Dexuan Cui > Sent: Tuesday, January 26, 2016 14:49 > To: Kylie Liang <kyliel@microsoft.com<mailto:kyliel@microsoft.com>>; Jac Backus > <j.backus@bugworks.com<mailto:j.backus@bugworks.com>>; 'freebsd-virtualization@freebsd.org' > <freebsd-virtualization@freebsd.org<mailto:freebsd-virtualization@freebsd.org>>; BSD Integration Components for > Hyper-V <bsdic@microsoft.com<mailto:bsdic@microsoft.com>> > Subject: RE: Hyper-V networking: problem after upgrade to 10.2 > > Hi Jac, > Kylie meant disabling TSO. Please try this ("ifconfig hn0 -tso"). > > The message " hn0: unknown status 1073872902 received" should be an > unnecessary warning only. > My 10.2 VM can work fine even if I see the message too. > > Can you please install a 10.2 VM from the 10.2 .ISO file directly as I > did and see if it works for you? > > I guess we never tried upgrading 10.1 from 10.2. > Can you please list the steps how you did the upgrading? We'll try the > same steps. > > Thanks, > -- Dexuan > > > -----Original Message----- > > From: Kylie Liang > > Sent: Tuesday, January 26, 2016 8:01 > > To: Jac Backus <j.backus@bugworks.com<mailto:j.backus@bugworks.com>>; 'freebsd- > virtualization@freebsd.org<mailto:virtualization@freebsd.org>' > > <freebsd-virtualization@freebsd.org<mailto:freebsd-virtualization@freebsd.org>>; BSD Integration Components for > > Hyper- > V > > <bsdic@microsoft.com<mailto:bsdic@microsoft.com>> > > Subject: RE: Hyper-V networking: problem after upgrade to 10.2 > > > > Hi Jac, > > > > Thank you for asking. To isolate your issue, could you please try > > disabling SO > on > > your 10.2 system first? Thank you. > > > > And I would like to confirm with you > > 1) You met issue for 10.2 kernel + 10.2 system > > 2) No issue for 10.1 kernel + 10.1 system > > 3) No issue for 10.1 kernel + 10.2 system > > > > Right? And add our engineers in the list. > > > > Thanks, > > Kylie Liang > > > > -----Original Message----- > > From: owner-freebsd-virtualization@freebsd.org<mailto:owner-freebsd-virtualization@freebsd.org> > > [mailto:owner-freebsd- virtualization@freebsd.org<mailto:virtualization@freebsd.org>] On Behalf Of Jac > > Backus > > Sent: Tuesday, January 26, 2016 5:56 AM > > To: 'freebsd-virtualization@freebsd.org' > > <freebsd-virtualization@freebsd.org<mailto:freebsd-virtualization@freebsd.org>> > > Subject: Hyper-V networking: problem after upgrade to 10.2 > > > > Dear reader, > > > > Today, I did upgrade FreeBSD 10.1 to 10.2 running on Hyper-V on a > > full > patched > > Windows Server 2012 R2 x64 version. > > > > After the update, networking does not work anymore. > > > > In /var/log/messages is this: > > > > Jan 25 21:02:01 mercurius kernel: hn0: <Synthetic Network Interface> > > on > > vmbus0 Jan 25 21:02:01 mercurius kernel: hn0: unknown status > > 1073872902 received Jan 25 21:02:01 mercurius kernel: hn0: unknown > > status 1073872902 received Jan 25 21:02:01 mercurius kernel: hn0: hv > > send offload request succeeded Jan 25 21:02:01 mercurius kernel: hn0: Using defaults for TSO: > > 65518/35/2048 Jan 25 21:02:01 mercurius kernel: hn0: Ethernet address: > > 00:15:5d:ac:11:08 Jan 25 21:02:01 mercurius kernel: hn1: <Synthetic > > Network > > Interface> on vmbus0 Jan 25 21:02:01 mercurius kernel: hn1: unknown > > Interface> status > > 1073872902 received Jan 25 21:02:01 mercurius kernel: hn1: unknown > > status > > 1073872902 received Jan 25 21:02:01 mercurius kernel: hn1: hv send > > offload request succeeded Jan 25 21:02:01 mercurius kernel: hn1: > > Using defaults for > TSO: > > 65518/35/2048 Jan 25 21:02:01 mercurius kernel: hn1: Ethernet address: > > 00:15:5d:ac:11:09 Jan 25 21:02:01 mercurius kernel: hn2: <Synthetic > > Network > > Interface> on vmbus0 Jan 25 21:02:01 mercurius kernel: hn2: unknown > > Interface> status > > 1073872902 received Jan 25 21:02:01 mercurius kernel: hn2: unknown > > status > > 1073872902 received Jan 25 21:02:01 mercurius kernel: hn2: hv send > > offload request succeeded Jan 25 21:02:01 mercurius kernel: hn2: > > Using defaults for > TSO: > > 65518/35/2048 Jan 25 21:02:01 mercurius kernel: hn2: Ethernet address: > > 00:15:5d:ac:11:07 > > > > It worked fine with the 10.1 kernel, and when I boot this kernel, it works again: > > > > Jan 25 22:20:02 mercurius kernel: hn0: <Synthetic Network Interface> > > on > > vmbus0 Jan 25 22:20:02 mercurius kernel: hn0: Ethernet address: > > 00:15:5d:ac:11:07 Jan 25 22:20:02 mercurius kernel: hn1: <Synthetic > > Network > > Interface> on vmbus0 Jan 25 22:20:02 mercurius kernel: hn1: Ethernet address: > > 00:15:5d:ac:11:08 Jan 25 22:20:02 mercurius kernel: hn2: <Synthetic > > Network > > Interface> on vmbus0 Jan 25 22:20:02 mercurius kernel: hn2: Ethernet address: > > 00:15:5d:ac:11:09 > > > > So I am running a 10.2 system on a 10.1 kernel at the moment. > > > > I found nothing in /usr/src/UPDATING and not really anything on the net. > > > > So, could you tell why does this happen, and how can I solve this? > > > > Thanks for the help! > > > > With kind regards, > > > > Jac Backus > > > > > > > > _______________________________________________ > > freebsd-virtualization@freebsd.org<mailto:freebsd-virtualization@freebsd.org> mailing list > > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2flists > .freebs > > d.org%2fmailman%2flistinfo%2ffreebsd- > > > virtualization&data=01%7c01%7ckyliel%40064d.mgd.microsoft.com%7cc9ca2e > > > 0d0fef482b553f08d325d3aefb%7c72f988bf86f141af91ab2d7cd011db47%7c1&s > > data=o%2bMZGuBW0frrQhjAPkhrWlLgNEH8LJ7BiLUyiO4tvR0%3d > > To unsubscribe, send any mail to "freebsd-virtualization- > > unsubscribe@freebsd.org<mailto:unsubscribe@freebsd.org>" [-- Attachment #2 --] # cat sys/dev/hyperv/vmbus/hv_channel_mgmt.c /*- * Copyright (c) 2009-2012 Microsoft Corp. * Copyright (c) 2012 NetApp Inc. * Copyright (c) 2012 Citrix Inc. * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice unmodified, this list of conditions, and the following * disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ #include <sys/cdefs.h> __FBSDID("$FreeBSD: releng/10.2/sys/dev/hyperv/vmbus/hv_channel_mgmt.c 283280 2015-05-22 09:03:55Z whu $"); #include <sys/param.h> #include <sys/mbuf.h> #include "hv_vmbus_priv.h" /* * Internal functions */ static void vmbus_channel_on_offer(hv_vmbus_channel_msg_header* hdr); static void vmbus_channel_on_open_result(hv_vmbus_channel_msg_header* hdr); static void vmbus_channel_on_offer_rescind(hv_vmbus_channel_msg_header* hdr); static void vmbus_channel_on_gpadl_created(hv_vmbus_channel_msg_header* hdr); static void vmbus_channel_on_gpadl_torndown(hv_vmbus_channel_msg_header* hdr); static void vmbus_channel_on_offers_delivered(hv_vmbus_channel_msg_header* hdr); static void vmbus_channel_on_version_response(hv_vmbus_channel_msg_header* hdr); static void vmbus_channel_process_offer(void *context); struct hv_vmbus_channel* vmbus_select_outgoing_channel(struct hv_vmbus_channel *promary); /** * Channel message dispatch table */ hv_vmbus_channel_msg_table_entry g_channel_message_table[HV_CHANNEL_MESSAGE_COUNT] = { { HV_CHANNEL_MESSAGE_INVALID, 0, NULL }, { HV_CHANNEL_MESSAGE_OFFER_CHANNEL, 0, vmbus_channel_on_offer }, { HV_CHANNEL_MESSAGE_RESCIND_CHANNEL_OFFER, 0, vmbus_channel_on_offer_rescind }, { HV_CHANNEL_MESSAGE_REQUEST_OFFERS, 0, NULL }, { HV_CHANNEL_MESSAGE_ALL_OFFERS_DELIVERED, 1, vmbus_channel_on_offers_delivered }, { HV_CHANNEL_MESSAGE_OPEN_CHANNEL, 0, NULL }, { HV_CHANNEL_MESSAGE_OPEN_CHANNEL_RESULT, 1, vmbus_channel_on_open_result }, { HV_CHANNEL_MESSAGE_CLOSE_CHANNEL, 0, NULL }, { HV_CHANNEL_MESSAGEL_GPADL_HEADER, 0, NULL }, { HV_CHANNEL_MESSAGE_GPADL_BODY, 0, NULL }, { HV_CHANNEL_MESSAGE_GPADL_CREATED, 1, vmbus_channel_on_gpadl_created }, { HV_CHANNEL_MESSAGE_GPADL_TEARDOWN, 0, NULL }, { HV_CHANNEL_MESSAGE_GPADL_TORNDOWN, 1, vmbus_channel_on_gpadl_torndown }, { HV_CHANNEL_MESSAGE_REL_ID_RELEASED, 0, NULL }, { HV_CHANNEL_MESSAGE_INITIATED_CONTACT, 0, NULL }, { HV_CHANNEL_MESSAGE_VERSION_RESPONSE, 1, vmbus_channel_on_version_response }, { HV_CHANNEL_MESSAGE_UNLOAD, 0, NULL } }; /** * Implementation of the work abstraction. */ static void work_item_callback(void *work, int pending) { struct hv_work_item *w = (struct hv_work_item *)work; /* * Serialize work execution. */ if (w->wq->work_sema != NULL) { sema_wait(w->wq->work_sema); } w->callback(w->context); if (w->wq->work_sema != NULL) { sema_post(w->wq->work_sema); } free(w, M_DEVBUF); } struct hv_work_queue* hv_work_queue_create(char* name) { static unsigned int qid = 0; char qname[64]; int pri; struct hv_work_queue* wq; wq = malloc(sizeof(struct hv_work_queue), M_DEVBUF, M_NOWAIT | M_ZERO); KASSERT(wq != NULL, ("Error VMBUS: Failed to allocate work_queue\n")); if (wq == NULL) return (NULL); /* * We use work abstraction to handle messages * coming from the host and these are typically offers. * Some FreeBsd drivers appear to have a concurrency issue * where probe/attach needs to be serialized. We ensure that * by having only one thread process work elements in a * specific queue by serializing work execution. * */ if (strcmp(name, "vmbusQ") == 0) { pri = PI_DISK; } else { /* control */ pri = PI_NET; /* * Initialize semaphore for this queue by pointing * to the globale semaphore used for synchronizing all * control messages. */ wq->work_sema = &hv_vmbus_g_connection.control_sema; } sprintf(qname, "hv_%s_%u", name, qid); /* * Fixme: FreeBSD 8.2 has a different prototype for * taskqueue_create(), and for certain other taskqueue functions. * We need to research the implications of these changes. * Fixme: Not sure when the changes were introduced. */ wq->queue = taskqueue_create(qname, M_NOWAIT, taskqueue_thread_enqueue, &wq->queue #if __FreeBSD_version < 800000 , &wq->proc #endif ); if (wq->queue == NULL) { free(wq, M_DEVBUF); return (NULL); } if (taskqueue_start_threads(&wq->queue, 1, pri, "%s taskq", qname)) { taskqueue_free(wq->queue); free(wq, M_DEVBUF); return (NULL); } qid++; return (wq); } void hv_work_queue_close(struct hv_work_queue *wq) { /* * KYS: Need to drain the taskqueue * before we close the hv_work_queue. */ /*KYS: taskqueue_drain(wq->tq, ); */ taskqueue_free(wq->queue); free(wq, M_DEVBUF); } /** * @brief Create work item */ int hv_queue_work_item( struct hv_work_queue *wq, void (*callback)(void *), void *context) { struct hv_work_item *w = malloc(sizeof(struct hv_work_item), M_DEVBUF, M_NOWAIT | M_ZERO); KASSERT(w != NULL, ("Error VMBUS: Failed to allocate WorkItem\n")); if (w == NULL) return (ENOMEM); w->callback = callback; w->context = context; w->wq = wq; TASK_INIT(&w->work, 0, work_item_callback, w); return (taskqueue_enqueue(wq->queue, &w->work)); } /** * @brief Allocate and initialize a vmbus channel object */ hv_vmbus_channel* hv_vmbus_allocate_channel(void) { hv_vmbus_channel* channel; channel = (hv_vmbus_channel*) malloc( sizeof(hv_vmbus_channel), M_DEVBUF, M_NOWAIT | M_ZERO); KASSERT(channel != NULL, ("Error VMBUS: Failed to allocate channel!")); if (channel == NULL) return (NULL); mtx_init(&channel->inbound_lock, "channel inbound", NULL, MTX_DEF); mtx_init(&channel->sc_lock, "vmbus multi channel", NULL, MTX_DEF); TAILQ_INIT(&channel->sc_list_anchor); return (channel); } /** * @brief Release the vmbus channel object itself */ static inline void ReleaseVmbusChannel(void *context) { hv_vmbus_channel* channel = (hv_vmbus_channel*) context; free(channel, M_DEVBUF); } /** * @brief Release the resources used by the vmbus channel object */ void hv_vmbus_free_vmbus_channel(hv_vmbus_channel* channel) { mtx_destroy(&channel->sc_lock); mtx_destroy(&channel->inbound_lock); /* * We have to release the channel's workqueue/thread in * the vmbus's workqueue/thread context * ie we can't destroy ourselves */ hv_queue_work_item(hv_vmbus_g_connection.work_queue, ReleaseVmbusChannel, (void *) channel); } /** * @brief Process the offer by creating a channel/device * associated with this offer */ static void vmbus_channel_process_offer(hv_vmbus_channel *new_channel) { boolean_t f_new; hv_vmbus_channel* channel; int ret; f_new = TRUE; channel = NULL; /* * Make sure this is a new offer */ mtx_lock(&hv_vmbus_g_connection.channel_lock); TAILQ_FOREACH(channel, &hv_vmbus_g_connection.channel_anchor, list_entry) { if (memcmp(&channel->offer_msg.offer.interface_type, &new_channel->offer_msg.offer.interface_type, sizeof(hv_guid)) == 0 && memcmp(&channel->offer_msg.offer.interface_instance, &new_channel->offer_msg.offer.interface_instance, sizeof(hv_guid)) == 0) { f_new = FALSE; break; } } if (f_new) { /* Insert at tail */ TAILQ_INSERT_TAIL( &hv_vmbus_g_connection.channel_anchor, new_channel, list_entry); } mtx_unlock(&hv_vmbus_g_connection.channel_lock); /*XXX add new channel to percpu_list */ if (!f_new) { /* * Check if this is a sub channel. */ if (new_channel->offer_msg.offer.sub_channel_index != 0) { /* * It is a sub channel offer, process it. */ new_channel->primary_channel = channel; mtx_lock(&channel->sc_lock); TAILQ_INSERT_TAIL( &channel->sc_list_anchor, new_channel, sc_list_entry); mtx_unlock(&channel->sc_lock); /* Insert new channel into channel_anchor. */ printf("Storvsc get multi-channel offer, rel=%u.\n", new_channel->offer_msg.child_rel_id); mtx_lock(&hv_vmbus_g_connection.channel_lock); TAILQ_INSERT_TAIL(&hv_vmbus_g_connection.channel_anchor, new_channel, list_entry); mtx_unlock(&hv_vmbus_g_connection.channel_lock); if(bootverbose) printf("VMBUS: new multi-channel offer <%p>.\n", new_channel); /*XXX add it to percpu_list */ new_channel->state = HV_CHANNEL_OPEN_STATE; if (channel->sc_creation_callback != NULL) { channel->sc_creation_callback(new_channel); } return; } hv_vmbus_free_vmbus_channel(new_channel); return; } new_channel->state = HV_CHANNEL_OPEN_STATE; /* * Start the process of binding this offer to the driver * (We need to set the device field before calling * hv_vmbus_child_device_add()) */ new_channel->device = hv_vmbus_child_device_create( new_channel->offer_msg.offer.interface_type, new_channel->offer_msg.offer.interface_instance, new_channel); /* * Add the new device to the bus. This will kick off device-driver * binding which eventually invokes the device driver's AddDevice() * method. */ ret = hv_vmbus_child_device_register(new_channel->device); if (ret != 0) { mtx_lock(&hv_vmbus_g_connection.channel_lock); TAILQ_REMOVE( &hv_vmbus_g_connection.channel_anchor, new_channel, list_entry); mtx_unlock(&hv_vmbus_g_connection.channel_lock); hv_vmbus_free_vmbus_channel(new_channel); } } /** * Array of device guids that are performance critical. We try to distribute * the interrupt load for these devices across all online cpus. */ static const hv_guid high_perf_devices[] = { {HV_NIC_GUID, }, {HV_IDE_GUID, }, {HV_SCSI_GUID, }, }; enum { PERF_CHN_NIC = 0, PERF_CHN_IDE, PERF_CHN_SCSI, MAX_PERF_CHN, }; /* * We use this static number to distribute the channel interrupt load. */ static uint32_t next_vcpu; /** * Starting with Win8, we can statically distribute the incoming * channel interrupt load by binding a channel to VCPU. We * implement here a simple round robin scheme for distributing * the interrupt load. * We will bind channels that are not performance critical to cpu 0 and * performance critical channels (IDE, SCSI and Network) will be uniformly * distributed across all available CPUs. */ static void vmbus_channel_select_cpu(hv_vmbus_channel *channel, hv_guid *guid) { uint32_t current_cpu; int i; boolean_t is_perf_channel = FALSE; for (i = PERF_CHN_NIC; i < MAX_PERF_CHN; i++) { if (memcmp(guid->data, high_perf_devices[i].data, sizeof(hv_guid)) == 0) { is_perf_channel = TRUE; break; } } if ((hv_vmbus_protocal_version == HV_VMBUS_VERSION_WS2008) || (hv_vmbus_protocal_version == HV_VMBUS_VERSION_WIN7) || (!is_perf_channel)) { /* Host's view of guest cpu */ channel->target_vcpu = 0; /* Guest's own view of cpu */ channel->target_cpu = 0; return; } /* mp_ncpus should have the number cpus currently online */ current_cpu = (++next_vcpu % mp_ncpus); channel->target_cpu = current_cpu; channel->target_vcpu = hv_vmbus_g_context.hv_vcpu_index[current_cpu]; if (bootverbose) printf("VMBUS: Total online cpus %d, assign perf channel %d " "to vcpu %d, cpu %d\n", mp_ncpus, i, channel->target_vcpu, current_cpu); } /** * @brief Handler for channel offers from Hyper-V/Azure * * Handler for channel offers from vmbus in parent partition. We ignore * all offers except network and storage offers. For each network and storage * offers, we create a channel object and queue a work item to the channel * object to process the offer synchronously */ static void vmbus_channel_on_offer(hv_vmbus_channel_msg_header* hdr) { hv_vmbus_channel_offer_channel* offer; hv_vmbus_channel* new_channel; offer = (hv_vmbus_channel_offer_channel*) hdr; hv_guid *guidType; hv_guid *guidInstance; guidType = &offer->offer.interface_type; guidInstance = &offer->offer.interface_instance; /* Allocate the channel object and save this offer */ new_channel = hv_vmbus_allocate_channel(); if (new_channel == NULL) return; /* * By default we setup state to enable batched * reading. A specific service can choose to * disable this prior to opening the channel. */ new_channel->batched_reading = TRUE; new_channel->signal_event_param = (hv_vmbus_input_signal_event *) (HV_ALIGN_UP((unsigned long) &new_channel->signal_event_buffer, HV_HYPERCALL_PARAM_ALIGN)); new_channel->signal_event_param->connection_id.as_uint32_t = 0; new_channel->signal_event_param->connection_id.u.id = HV_VMBUS_EVENT_CONNECTION_ID; new_channel->signal_event_param->flag_number = 0; new_channel->signal_event_param->rsvd_z = 0; if (hv_vmbus_protocal_version != HV_VMBUS_VERSION_WS2008) { new_channel->is_dedicated_interrupt = (offer->is_dedicated_interrupt != 0); new_channel->signal_event_param->connection_id.u.id = offer->connection_id; } /* * Bind the channel to a chosen cpu. */ vmbus_channel_select_cpu(new_channel, &offer->offer.interface_type); memcpy(&new_channel->offer_msg, offer, sizeof(hv_vmbus_channel_offer_channel)); new_channel->monitor_group = (uint8_t) offer->monitor_id / 32; new_channel->monitor_bit = (uint8_t) offer->monitor_id % 32; vmbus_channel_process_offer(new_channel); } /** * @brief Rescind offer handler. * * We queue a work item to process this offer * synchronously */ static void vmbus_channel_on_offer_rescind(hv_vmbus_channel_msg_header* hdr) { hv_vmbus_channel_rescind_offer* rescind; hv_vmbus_channel* channel; rescind = (hv_vmbus_channel_rescind_offer*) hdr; channel = hv_vmbus_get_channel_from_rel_id(rescind->child_rel_id); if (channel == NULL) return; hv_vmbus_child_device_unregister(channel->device); } /** * * @brief Invoked when all offers have been delivered. */ static void vmbus_channel_on_offers_delivered(hv_vmbus_channel_msg_header* hdr) { } /** * @brief Open result handler. * * This is invoked when we received a response * to our channel open request. Find the matching request, copy the * response and signal the requesting thread. */ static void vmbus_channel_on_open_result(hv_vmbus_channel_msg_header* hdr) { hv_vmbus_channel_open_result* result; hv_vmbus_channel_msg_info* msg_info; hv_vmbus_channel_msg_header* requestHeader; hv_vmbus_channel_open_channel* openMsg; result = (hv_vmbus_channel_open_result*) hdr; /* * Find the open msg, copy the result and signal/unblock the wait event */ mtx_lock_spin(&hv_vmbus_g_connection.channel_msg_lock); TAILQ_FOREACH(msg_info, &hv_vmbus_g_connection.channel_msg_anchor, msg_list_entry) { requestHeader = (hv_vmbus_channel_msg_header*) msg_info->msg; if (requestHeader->message_type == HV_CHANNEL_MESSAGE_OPEN_CHANNEL) { openMsg = (hv_vmbus_channel_open_channel*) msg_info->msg; if (openMsg->child_rel_id == result->child_rel_id && openMsg->open_id == result->open_id) { memcpy(&msg_info->response.open_result, result, sizeof(hv_vmbus_channel_open_result)); sema_post(&msg_info->wait_sema); break; } } } mtx_unlock_spin(&hv_vmbus_g_connection.channel_msg_lock); } /** * @brief GPADL created handler. * * This is invoked when we received a response * to our gpadl create request. Find the matching request, copy the * response and signal the requesting thread. */ static void vmbus_channel_on_gpadl_created(hv_vmbus_channel_msg_header* hdr) { hv_vmbus_channel_gpadl_created* gpadl_created; hv_vmbus_channel_msg_info* msg_info; hv_vmbus_channel_msg_header* request_header; hv_vmbus_channel_gpadl_header* gpadl_header; gpadl_created = (hv_vmbus_channel_gpadl_created*) hdr; /* Find the establish msg, copy the result and signal/unblock * the wait event */ mtx_lock_spin(&hv_vmbus_g_connection.channel_msg_lock); TAILQ_FOREACH(msg_info, &hv_vmbus_g_connection.channel_msg_anchor, msg_list_entry) { request_header = (hv_vmbus_channel_msg_header*) msg_info->msg; if (request_header->message_type == HV_CHANNEL_MESSAGEL_GPADL_HEADER) { gpadl_header = (hv_vmbus_channel_gpadl_header*) request_header; if ((gpadl_created->child_rel_id == gpadl_header->child_rel_id) && (gpadl_created->gpadl == gpadl_header->gpadl)) { memcpy(&msg_info->response.gpadl_created, gpadl_created, sizeof(hv_vmbus_channel_gpadl_created)); sema_post(&msg_info->wait_sema); break; } } } mtx_unlock_spin(&hv_vmbus_g_connection.channel_msg_lock); } /** * @brief GPADL torndown handler. * * This is invoked when we received a respons * to our gpadl teardown request. Find the matching request, copy the * response and signal the requesting thread */ static void vmbus_channel_on_gpadl_torndown(hv_vmbus_channel_msg_header* hdr) { hv_vmbus_channel_gpadl_torndown* gpadl_torndown; hv_vmbus_channel_msg_info* msg_info; hv_vmbus_channel_msg_header* requestHeader; hv_vmbus_channel_gpadl_teardown* gpadlTeardown; gpadl_torndown = (hv_vmbus_channel_gpadl_torndown*)hdr; /* * Find the open msg, copy the result and signal/unblock the * wait event. */ mtx_lock_spin(&hv_vmbus_g_connection.channel_msg_lock); TAILQ_FOREACH(msg_info, &hv_vmbus_g_connection.channel_msg_anchor, msg_list_entry) { requestHeader = (hv_vmbus_channel_msg_header*) msg_info->msg; if (requestHeader->message_type == HV_CHANNEL_MESSAGE_GPADL_TEARDOWN) { gpadlTeardown = (hv_vmbus_channel_gpadl_teardown*) requestHeader; if (gpadl_torndown->gpadl == gpadlTeardown->gpadl) { memcpy(&msg_info->response.gpadl_torndown, gpadl_torndown, sizeof(hv_vmbus_channel_gpadl_torndown)); sema_post(&msg_info->wait_sema); break; } } } mtx_unlock_spin(&hv_vmbus_g_connection.channel_msg_lock); } /** * @brief Version response handler. * * This is invoked when we received a response * to our initiate contact request. Find the matching request, copy th * response and signal the requesting thread. */ static void vmbus_channel_on_version_response(hv_vmbus_channel_msg_header* hdr) { hv_vmbus_channel_msg_info* msg_info; hv_vmbus_channel_msg_header* requestHeader; hv_vmbus_channel_initiate_contact* initiate; hv_vmbus_channel_version_response* versionResponse; versionResponse = (hv_vmbus_channel_version_response*)hdr; mtx_lock_spin(&hv_vmbus_g_connection.channel_msg_lock); TAILQ_FOREACH(msg_info, &hv_vmbus_g_connection.channel_msg_anchor, msg_list_entry) { requestHeader = (hv_vmbus_channel_msg_header*) msg_info->msg; if (requestHeader->message_type == HV_CHANNEL_MESSAGE_INITIATED_CONTACT) { initiate = (hv_vmbus_channel_initiate_contact*) requestHeader; memcpy(&msg_info->response.version_response, versionResponse, sizeof(hv_vmbus_channel_version_response)); sema_post(&msg_info->wait_sema); } } mtx_unlock_spin(&hv_vmbus_g_connection.channel_msg_lock); } /** * @brief Handler for channel protocol messages. * * This is invoked in the vmbus worker thread context. */ void hv_vmbus_on_channel_message(void *context) { hv_vmbus_message* msg; hv_vmbus_channel_msg_header* hdr; int size; msg = (hv_vmbus_message*) context; hdr = (hv_vmbus_channel_msg_header*) msg->u.payload; size = msg->header.payload_size; if (hdr->message_type >= HV_CHANNEL_MESSAGE_COUNT) { free(msg, M_DEVBUF); return; } if (g_channel_message_table[hdr->message_type].messageHandler) { g_channel_message_table[hdr->message_type].messageHandler(hdr); } /* Free the msg that was allocated in VmbusOnMsgDPC() */ free(msg, M_DEVBUF); } /** * @brief Send a request to get all our pending offers. */ int hv_vmbus_request_channel_offers(void) { int ret; hv_vmbus_channel_msg_header* msg; hv_vmbus_channel_msg_info* msg_info; msg_info = (hv_vmbus_channel_msg_info *) malloc(sizeof(hv_vmbus_channel_msg_info) + sizeof(hv_vmbus_channel_msg_header), M_DEVBUF, M_NOWAIT); if (msg_info == NULL) { if(bootverbose) printf("Error VMBUS: malloc failed for Request Offers\n"); return (ENOMEM); } msg = (hv_vmbus_channel_msg_header*) msg_info->msg; msg->message_type = HV_CHANNEL_MESSAGE_REQUEST_OFFERS; ret = hv_vmbus_post_message(msg, sizeof(hv_vmbus_channel_msg_header)); if (msg_info) free(msg_info, M_DEVBUF); return (ret); } /** * @brief Release channels that are unattached/unconnected (i.e., no drivers associated) */ void hv_vmbus_release_unattached_channels(void) { hv_vmbus_channel *channel; mtx_lock(&hv_vmbus_g_connection.channel_lock); while (!TAILQ_EMPTY(&hv_vmbus_g_connection.channel_anchor)) { channel = TAILQ_FIRST(&hv_vmbus_g_connection.channel_anchor); TAILQ_REMOVE(&hv_vmbus_g_connection.channel_anchor, channel, list_entry); hv_vmbus_child_device_unregister(channel->device); hv_vmbus_free_vmbus_channel(channel); } mtx_unlock(&hv_vmbus_g_connection.channel_lock); } /** * @brief Select the best outgoing channel * * The channel whose vcpu binding is closest to the currect vcpu will * be selected. * If no multi-channel, always select primary channel * * @param primary - primary channel */ struct hv_vmbus_channel * vmbus_select_outgoing_channel(struct hv_vmbus_channel *primary) { hv_vmbus_channel *new_channel = NULL; hv_vmbus_channel *outgoing_channel = primary; int old_cpu_distance = 0; int new_cpu_distance = 0; int cur_vcpu = 0; int smp_pro_id = PCPU_GET(cpuid); if (TAILQ_EMPTY(&primary->sc_list_anchor)) { return outgoing_channel; } if (smp_pro_id >= MAXCPU) { return outgoing_channel; } cur_vcpu = hv_vmbus_g_context.hv_vcpu_index[smp_pro_id]; TAILQ_FOREACH(new_channel, &primary->sc_list_anchor, sc_list_entry) { if (new_channel->state != HV_CHANNEL_OPENED_STATE){ continue; } if (new_channel->target_vcpu == cur_vcpu){ return new_channel; } old_cpu_distance = ((outgoing_channel->target_vcpu > cur_vcpu) ? (outgoing_channel->target_vcpu - cur_vcpu) : (cur_vcpu - outgoing_channel->target_vcpu)); new_cpu_distance = ((new_channel->target_vcpu > cur_vcpu) ? (new_channel->target_vcpu - cur_vcpu) : (cur_vcpu - new_channel->target_vcpu)); if (old_cpu_distance < new_cpu_distance) { continue; } outgoing_channel = new_channel; } return(outgoing_channel); }help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53238096372f4362b436382a430bde57>