Re: NetBSD-current under Hyper-V (Déjà vu...)

[Brad Spencer <brad%anduin.eldar.org@localhost>]

   Hi,

   Five years to the day, I post the same. I'd agree that it is not
   particularly important, google returns mostly rehashes of my post (
   http://mail-index.netbsd.org/current-users/2008/04/24/msg001989.html
   )when I search for 'NetBSD Hyper-V', so I guess I am one of the very
   few trying to do that.

I messed with this recently too.  I used a Windows 8 Pro laptop for the
test.

   Basically, one has to boot netbsd -12 (both i386 and amd64) in order
   to get usable system, otherwise one gets the the timeout messages
   described in the above reference and no communication. In addition
   there is something wrong with some keyboard timeouts, I guess - long
   repeats are initiated very easily in this case, one has to be very
   careful not to overstay the keypress more than a fraction of a second.
   With ACPI and SMP disabled the tulip driver (legacy network adapter in
   Microsoft's parlance) weems to work OK (only 'tlp: receive ruing
   overrun' messages are seen from time to time, but the communication is
   OK). Solaris/Illumos with the dnet driver works fine, FreeBSD is a
   mixed bag (works on the full Hyper-V 3.0, refuses on the Windows 8
   variety), OpenBSD is not working as well (but I haven't tried similar
   to NetBSDs workarounds yet).

Yes, ACPI and SMP need to be disabled or tlp won't work.  However, I found
out something quite interesting....

You can boot Xen under Hyper-V and run NetBSD there.  One may be asking
why you would do that.  The answer for me is that ACPI and SMP "work".
That is, the tlp driver does not have the issues mentioned and ACPI and
friends can stay enabled.  You can even start PV sub guests, if you like,
although I had trouble getting networking out to the larger world from the
Xen DOMU working.

However, there are more problems, likely with Hyper-V itself, that make
the whole thing suspect:

1) I can crash my laptop on demand from the guest.  The bridge driver
   seems to be quite buggy and if you run in "external" mode, where the
   guest is bridged to the same network as the hosting computer, you can
   trigger a Windows 8 BSOD.  You can Google "windows 8 bridge BSOD" and
   see more on this.

2) The Windows network bridge stops working after a time.  That is, the
   guest is just fine sending and receiving packets from the larger world,
   and the after a short number of packets, the bridge in Windows 8 stops
   passing traffic.  Using Xen didn't help this.  I have not tried using
   the nonbridge, "external", modes.


   There is an ongoing project to port the synthetic driver and the rest
   to FreeBSD - see http://freebsdonhyper-v.github.io/ ; this is
   presently for FreeBSD 8.2, I don't know if it will be very hard to
   port it to NetBSD (and that certainly is beyond my abilities, I could
   help with testing of course).

   I tried to go through the tulip code, but couldn't find anything
   obvious (and as it is connected with the watchdog and the ACPI code,
   suspected that the problem is deeper than the driver code itself ).

   As the french would say it, "plus ça change, plus c'est la même chose"...


   Regards,

   Chavdar Ivanov
   --
   ----


-- 
Brad Spencer - brad%anduin.eldar.org@localhost - KC8VKS
http://anduin.eldar.org  - & -  http://anduin.ipv6.eldar.org [IPv6 only]