Hi, I decided to reuse this thread; nvmm again ceased to work from yesterday.
On # uname -a NetBSD ymir 9.99.69 NetBSD 9.99.69 (GENERIC) #15: Tue Jul 14 11:07:52 BST 2020 sysbuild@ymir:/home/sysbuild/amd64/obj/home/sysbuild/src/sys /arch/amd64/compile/GENERIC amd64 I can 'modload nvmm', but when I try to start a vm with nvmm acceleration, I get a hard lock, immediately after the message about the interface being initialized. I cannot break into the debugger to trace and I don't get a dump on reboot. It appears the machine is in a deep CPU loop, although it doesn't appear too hot. I then tried booting onetbsd, which is from the 12th of July and on which nvmm used to work just fine. It is also the same micro version - 9.99.59, so n theory should work - but in this case I get a panic when I 'modload nvmm' - again, I see the short panic message on the screen and the machine apparently gets into another loop here, which I cannot break the usual way into the debugger and the only thing I can do is hit the power button. There weren't that many kernel changes in this period, most notably the per-CPU IDT patch, but I don't know if it is relevant. Chavdar On Wed, 20 May 2020 at 22:09, Maxime Villard <m...@m00nbsd.net> wrote: > > Le 09/05/2020 à 10:54, Maxime Villard a écrit : > > Le 01/05/2020 à 19:13, Chavdar Ivanov a écrit : > >> On Fri, 1 May 2020 at 13:59, Rhialto <rhia...@falu.nl> wrote: > >>> > >>> On Sun 26 Apr 2020 at 21:39:12 +0200, Maxime Villard wrote: > >>>> Maybe I should add a note in the man page to say that you cannot expect > >>>> a CPU > >>>> from before ~2010 to have virtualization support. > >>> > >>> Or even better, what one should look for in the output of, for example, > >>> "cpuctl identify 0". Since I didn't exactly know, I made some guesses > >>> and assumed that my cpu ("Intel(R) Core(TM) i3-2120 CPU @ 3.30GHz") > >>> did't have the required features (it is from 2009 or so). But this > >>> thread inspired me to modload nvmm, which actually helped, so I found > >>> out that it even works on this cpu. > > > > On Intel CPUs the information is hidden in privileged registers that cpuctl > > cannot access, so no, it won't be possible. > > > > However the day before I had added clear warnings: > > > > https://mail-index.netbsd.org/source-changes/2020/04/30/msg116878.html > > > > So now it will tell you what's missing. > > > >>> Of course I immediately tried it with Haiku (the BeOS clone) from > >>> https://download.haiku-os.org/nightly-images/x86_64/ and I got mixed > >>> results. Once it manages to boot it works fine and nicely fast (much > >>> better than without nvmm), but quite often it crashes into its kernel > >>> debugger during the first 10 seconds of booting, with different messages > >>> (I have seen "General Protection Exception" and "ASSERT failed ... > >>> fCPUCount >= 0"). ("qemu-system-x86_64 -accel nvmm -m 2G -cdrom > >>> haiku-master-hrev54106-x86_64-anyboot.iso" on a 9.0 GENERIC kernel) > > > > This was a missing filtering in the CPU identification, on CPUs that have > > SMT, > > leading Haiku to believe it had SMT threads that it didn't. > > > > https://mail-index.netbsd.org/source-changes/2020/05/09/msg117188.html > > > > As far as I can tell, your CPU has SMT. > > > >> I've never used Haiku so far; upon reading this I decided to try it on > >> my NetBSD-current laptop with nvmm. > >> > >> So far, with several attempts, it works with no problem whatsoever, > >> directly booting the newest image on the site pointed above. > >> > >> Another OS to play with... > >> > >> The host cpu is Intel(R) Core(TM) i7-3820QM CPU @ 2.70GHz, id 0x306a9. > > > > This CPU too has SMT. > > > > Le 01/05/2020 à 20:10, Rhialto a écrit : > >> There might well be an improvement between 9.0 and -current, of course. > >> It's good to hear that it works for you; I might upgrade to a -current > >> kernel. > > > > Overall, no, each improvement in -current is propagated to 9, so you should > > get the same results on both (modulo kernel bugs added in places not > > related to NVMM). > > > > Le 01/05/2020 à 20:52, Chavdar Ivanov a écrit : > >> Earlier I had similar issues with OmniOS under qemu-nvmm - sometimes > >> it worked without a problem, sometimes I couldn't even boot. I still > >> have no idea why. > > > > Maybe that's the same problem, I'll test. > > I tested the other day, and I saw no problem. With debugging I noticed that > OmniOS, too, uses the CPU information that used to be mis-reported by NVMM, > so probably my fix must have helped. > > Please confirm the issues are fixed (HaikuOS+OmniOS). -- ----