Re: NVMM not working, NetBSD 9x amd64
On Thu, 16 Jul 2020 at 21:21, Chavdar Ivanov wrote: > > On Wed, 15 Jul 2020 at 14:25, Chavdar Ivanov wrote: > > > > Checking once more, it would appear I haven't tried qemu-nvmm on the > > kernel from 12-th of July; the last successful execution was on the > > 11th with a kernel and system from the 9th of July, so the window is a > > bit wider than initially expected. > > > Does anybody use nvmm under -current at all? It hasn't been functional > since at least the 12th of July, e.g. > > (crash immediately after starting up a Linux guest) > . > crash -M netbsd.22.core -N netbsd.22 > Crash version 9.99.69, image version 9.99.69. > crash: _kvm_kvatop(0) > Kernel compiled without options LOCKDEBUG. > System panicked: trap > Backtrace from time of crash is available. > crash> bt > _KERNEL_OPT_NARCNET() at 0 > ?() at a0819ba16000 > sys_reboot() at sys_reboot > vpanic() at vpanic+0x15b > snprintf() at snprintf > startlwp() at startlwp > calltrap() at calltrap+0x19 > kqueue_register() at kqueue_register+0x43e > kevent1() at kevent1+0x138 > sys___kevent50() at sys___kevent50+0x33 > syscall() at syscall+0x26e > --- syscall (number 435) --- > syscall+0x26e: > > and > > (starting a Windows 10 x86 guest - does not panic, system continues to > respond to ping, no further input is possible though, in this case I > can get into the debugger, here is the not very useful trace) > > crash> bt > _KERNEL_OPT_NARCNET() at 0 > _KERNEL_OPT_ACPI_SCANPCI() at _KERNEL_OPT_ACPI_SCANPCI+0x5 > sys_reboot() at sys_reboot > db_fncall() at db_fncall > db_command() at db_command+0x127 > db_command_loop() at db_command_loop+0xa6 > db_trap() at db_trap+0xe6 > kdb_trap() at kdb_trap+0xe1 > trap() at trap+0x2b7 > --- trap (number 1) --- > breakpoint() at breakpoint+0x5 > wskbd_translate() at wskbd_translate+0xff5 > wskbd_input() at wskbd_input+0xbe > pckbd_input() at pckbd_input+0x7f > pckbcintr() at pckbcintr+0x6a > intr_biglock_wrapper() at intr_biglock_wrapper+0x23 > > When I try to start a FreeBSD 12 guest, machine locks hard. > > > > > > On Wed, 15 Jul 2020 at 14:20, Chavdar Ivanov wrote: > > > > > > On Wed, 15 Jul 2020 at 11:08, Chavdar Ivanov wrote: > > > > > > > > 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. > > > > > > > > > > I rebuilt my system again today, this time I managed to get a core > > > dump after the panic: > > > > > > crash -M netbsd.22.core -N netbsd.22 > > > Crash version 9.99.69, image version 9.99.69. > > > crash: _kvm_kvatop(0) > > > Kernel compiled without options LOCKDEBUG. > > > System panicked: trap > > > Backtrace from time of crash is available. > > > crash> bt > > > _KERNEL_OPT_NARCNET() at 0 > > > ?() at a0819ba16000 > > > sys_reboot() at sys_reboot > > > vpanic() at vpanic+0x15b > > > snprintf() at snprintf > > > startlwp() at startlwp > > > calltrap() at calltrap+0x19 > > > kqueue_register() at kqueue_register+0x43e > > > kevent1() at kevent1+0x138 > > > sys___kevent50() at sys___kevent50+0x33 > > > syscall() at syscall+0x26e > > > --- syscall (number 435) --- > > > syscall+0x26e: > > > > > > Any ideas? > > > > > > The dmesg shows, BTW: > > > > > > Jul 15 14:09:33 ymir /netbsd: [ 108.7517032] nvmm0: attached, using > > > backend x86-vmx > > > Jul 15 14:11:40 ymir syslogd[946]: restart > > > Jul 15 14:11:40 ymir /netbsd: [ 131.2116186] fatal protection fault in > > > supervisor mode > > > Jul 15 14:11:40 ymir /netbsd: [ 131.2116186] trap type 4 code 0x323 > > > rip 0x80c89e21 cs 0x8 rflags 0x10282 cr2 0x784321f9f000 ilevel > > > 0 > > > rsp 0xa0819ba1ac50 > > > Jul 15 14:11:40 ymir /netbsd: [ 131.2116186] curlwp 0xd066fc45b100 > > > pid 2869.2869 lowest kstack
Re: NVMM not working, NetBSD 9x amd64
On Wed, 15 Jul 2020 at 14:25, Chavdar Ivanov wrote: > > Checking once more, it would appear I haven't tried qemu-nvmm on the > kernel from 12-th of July; the last successful execution was on the > 11th with a kernel and system from the 9th of July, so the window is a > bit wider than initially expected. Does anybody use nvmm under -current at all? It hasn't been functional since at least the 12th of July, e.g. (crash immediately after starting up a Linux guest) . crash -M netbsd.22.core -N netbsd.22 Crash version 9.99.69, image version 9.99.69. crash: _kvm_kvatop(0) Kernel compiled without options LOCKDEBUG. System panicked: trap Backtrace from time of crash is available. crash> bt _KERNEL_OPT_NARCNET() at 0 ?() at a0819ba16000 sys_reboot() at sys_reboot vpanic() at vpanic+0x15b snprintf() at snprintf startlwp() at startlwp calltrap() at calltrap+0x19 kqueue_register() at kqueue_register+0x43e kevent1() at kevent1+0x138 sys___kevent50() at sys___kevent50+0x33 syscall() at syscall+0x26e --- syscall (number 435) --- syscall+0x26e: and (starting a Windows 10 x86 guest - does not panic, system continues to respond to ping, no further input is possible though, in this case I can get into the debugger, here is the not very useful trace) crash> bt _KERNEL_OPT_NARCNET() at 0 _KERNEL_OPT_ACPI_SCANPCI() at _KERNEL_OPT_ACPI_SCANPCI+0x5 sys_reboot() at sys_reboot db_fncall() at db_fncall db_command() at db_command+0x127 db_command_loop() at db_command_loop+0xa6 db_trap() at db_trap+0xe6 kdb_trap() at kdb_trap+0xe1 trap() at trap+0x2b7 --- trap (number 1) --- breakpoint() at breakpoint+0x5 wskbd_translate() at wskbd_translate+0xff5 wskbd_input() at wskbd_input+0xbe pckbd_input() at pckbd_input+0x7f pckbcintr() at pckbcintr+0x6a intr_biglock_wrapper() at intr_biglock_wrapper+0x23 When I try to start a FreeBSD 12 guest, machine locks hard. > > On Wed, 15 Jul 2020 at 14:20, Chavdar Ivanov wrote: > > > > On Wed, 15 Jul 2020 at 11:08, Chavdar Ivanov wrote: > > > > > > 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. > > > > > > > I rebuilt my system again today, this time I managed to get a core > > dump after the panic: > > > > crash -M netbsd.22.core -N netbsd.22 > > Crash version 9.99.69, image version 9.99.69. > > crash: _kvm_kvatop(0) > > Kernel compiled without options LOCKDEBUG. > > System panicked: trap > > Backtrace from time of crash is available. > > crash> bt > > _KERNEL_OPT_NARCNET() at 0 > > ?() at a0819ba16000 > > sys_reboot() at sys_reboot > > vpanic() at vpanic+0x15b > > snprintf() at snprintf > > startlwp() at startlwp > > calltrap() at calltrap+0x19 > > kqueue_register() at kqueue_register+0x43e > > kevent1() at kevent1+0x138 > > sys___kevent50() at sys___kevent50+0x33 > > syscall() at syscall+0x26e > > --- syscall (number 435) --- > > syscall+0x26e: > > > > Any ideas? > > > > The dmesg shows, BTW: > > > > Jul 15 14:09:33 ymir /netbsd: [ 108.7517032] nvmm0: attached, using > > backend x86-vmx > > Jul 15 14:11:40 ymir syslogd[946]: restart > > Jul 15 14:11:40 ymir /netbsd: [ 131.2116186] fatal protection fault in > > supervisor mode > > Jul 15 14:11:40 ymir /netbsd: [ 131.2116186] trap type 4 code 0x323 > > rip 0x80c89e21 cs 0x8 rflags 0x10282 cr2 0x784321f9f000 ilevel > > 0 > > rsp 0xa0819ba1ac50 > > Jul 15 14:11:40 ymir /netbsd: [ 131.2116186] curlwp 0xd066fc45b100 > > pid 2869.2869 lowest kstack 0xa0819ba162c0 > > Jul 15 14:11:40 ymir /netbsd: [ 131.2116186] panic: trap > > Jul 15 14:11:40 ymir /netbsd: [ 131.2116186] cpu0: Begin traceback... > > Jul 15 14:11:40 ymir /netbsd: [ 131.2116186] vpanic() at netbsd:vpanic+0x152 > > Jul 15 14:11:40 ymir /netbsd: [ 131.2116186] snprintf() at netbsd:snprintf > > Jul 15 14:11:40
Re: NVMM not working, NetBSD 9x amd64
Checking once more, it would appear I haven't tried qemu-nvmm on the kernel from 12-th of July; the last successful execution was on the 11th with a kernel and system from the 9th of July, so the window is a bit wider than initially expected. On Wed, 15 Jul 2020 at 14:20, Chavdar Ivanov wrote: > > On Wed, 15 Jul 2020 at 11:08, Chavdar Ivanov wrote: > > > > 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. > > > > I rebuilt my system again today, this time I managed to get a core > dump after the panic: > > crash -M netbsd.22.core -N netbsd.22 > Crash version 9.99.69, image version 9.99.69. > crash: _kvm_kvatop(0) > Kernel compiled without options LOCKDEBUG. > System panicked: trap > Backtrace from time of crash is available. > crash> bt > _KERNEL_OPT_NARCNET() at 0 > ?() at a0819ba16000 > sys_reboot() at sys_reboot > vpanic() at vpanic+0x15b > snprintf() at snprintf > startlwp() at startlwp > calltrap() at calltrap+0x19 > kqueue_register() at kqueue_register+0x43e > kevent1() at kevent1+0x138 > sys___kevent50() at sys___kevent50+0x33 > syscall() at syscall+0x26e > --- syscall (number 435) --- > syscall+0x26e: > > Any ideas? > > The dmesg shows, BTW: > > Jul 15 14:09:33 ymir /netbsd: [ 108.7517032] nvmm0: attached, using > backend x86-vmx > Jul 15 14:11:40 ymir syslogd[946]: restart > Jul 15 14:11:40 ymir /netbsd: [ 131.2116186] fatal protection fault in > supervisor mode > Jul 15 14:11:40 ymir /netbsd: [ 131.2116186] trap type 4 code 0x323 > rip 0x80c89e21 cs 0x8 rflags 0x10282 cr2 0x784321f9f000 ilevel > 0 > rsp 0xa0819ba1ac50 > Jul 15 14:11:40 ymir /netbsd: [ 131.2116186] curlwp 0xd066fc45b100 > pid 2869.2869 lowest kstack 0xa0819ba162c0 > Jul 15 14:11:40 ymir /netbsd: [ 131.2116186] panic: trap > Jul 15 14:11:40 ymir /netbsd: [ 131.2116186] cpu0: Begin traceback... > Jul 15 14:11:40 ymir /netbsd: [ 131.2116186] vpanic() at netbsd:vpanic+0x152 > Jul 15 14:11:40 ymir /netbsd: [ 131.2116186] snprintf() at netbsd:snprintf > Jul 15 14:11:40 ymir /netbsd: [ 131.2116186] startlwp() at netbsd:startlwp > Jul 15 14:11:40 ymir /netbsd: [ 131.2116186] alltraps() at > netbsd:alltraps+0xc3 > Jul 15 14:11:40 ymir /netbsd: [ 131.2116186] kqueue_register() at > netbsd:kqueue_register+0x43e > Jul 15 14:11:40 ymir /netbsd: [ 131.2116186] kevent1() at netbsd:kevent1+0x138 > Jul 15 14:11:40 ymir /netbsd: [ 131.2116186] sys___kevent50() at > netbsd:sys___kevent50+0x33 > Jul 15 14:11:40 ymir /netbsd: [ 131.2116186] syscall() at netbsd:syscall+0x26e > Jul 15 14:11:40 ymir /netbsd: [ 131.2116186] --- syscall (number 435) --- > Jul 15 14:11:40 ymir /netbsd: [ 131.2216185] netbsd:syscall+0x26e: > Jul 15 14:11:40 ymir /netbsd: [ 131.2216185] cpu0: End traceback... > Jul 15 14:11:40 ymir /netbsd: > Jul 15 14:11:40 ymir /netbsd: [ 131.2216185] dumping to dev 168,2 > (offset=8, size=5225879): > Jul 15 14:11:40 ymir /netbsd: [ 131.2216185] dump <5>ktrace timeout > Jul 15 14:11:40 ymir /netbsd: ktrace timeout > Jul 15 14:11:40 ymir /netbsd: [ 131.2216185] ktrace timeout > Jul 15 14:11:40 ymir syslogd[946]: last message repeated 2 times > > > Chavdar > > > > On Wed, 20 May 2020 at 22:09, Maxime Villard 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 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
Re: NVMM not working, NetBSD 9x amd64
On Wed, 15 Jul 2020 at 11:08, Chavdar Ivanov wrote:
>
> 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.
>
I rebuilt my system again today, this time I managed to get a core
dump after the panic:
crash -M netbsd.22.core -N netbsd.22
Crash version 9.99.69, image version 9.99.69.
crash: _kvm_kvatop(0)
Kernel compiled without options LOCKDEBUG.
System panicked: trap
Backtrace from time of crash is available.
crash> bt
_KERNEL_OPT_NARCNET() at 0
?() at a0819ba16000
sys_reboot() at sys_reboot
vpanic() at vpanic+0x15b
snprintf() at snprintf
startlwp() at startlwp
calltrap() at calltrap+0x19
kqueue_register() at kqueue_register+0x43e
kevent1() at kevent1+0x138
sys___kevent50() at sys___kevent50+0x33
syscall() at syscall+0x26e
--- syscall (number 435) ---
syscall+0x26e:
Any ideas?
The dmesg shows, BTW:
Jul 15 14:09:33 ymir /netbsd: [ 108.7517032] nvmm0: attached, using
backend x86-vmx
Jul 15 14:11:40 ymir syslogd[946]: restart
Jul 15 14:11:40 ymir /netbsd: [ 131.2116186] fatal protection fault in
supervisor mode
Jul 15 14:11:40 ymir /netbsd: [ 131.2116186] trap type 4 code 0x323
rip 0x80c89e21 cs 0x8 rflags 0x10282 cr2 0x784321f9f000 ilevel
0
rsp 0xa0819ba1ac50
Jul 15 14:11:40 ymir /netbsd: [ 131.2116186] curlwp 0xd066fc45b100
pid 2869.2869 lowest kstack 0xa0819ba162c0
Jul 15 14:11:40 ymir /netbsd: [ 131.2116186] panic: trap
Jul 15 14:11:40 ymir /netbsd: [ 131.2116186] cpu0: Begin traceback...
Jul 15 14:11:40 ymir /netbsd: [ 131.2116186] vpanic() at netbsd:vpanic+0x152
Jul 15 14:11:40 ymir /netbsd: [ 131.2116186] snprintf() at netbsd:snprintf
Jul 15 14:11:40 ymir /netbsd: [ 131.2116186] startlwp() at netbsd:startlwp
Jul 15 14:11:40 ymir /netbsd: [ 131.2116186] alltraps() at netbsd:alltraps+0xc3
Jul 15 14:11:40 ymir /netbsd: [ 131.2116186] kqueue_register() at
netbsd:kqueue_register+0x43e
Jul 15 14:11:40 ymir /netbsd: [ 131.2116186] kevent1() at netbsd:kevent1+0x138
Jul 15 14:11:40 ymir /netbsd: [ 131.2116186] sys___kevent50() at
netbsd:sys___kevent50+0x33
Jul 15 14:11:40 ymir /netbsd: [ 131.2116186] syscall() at netbsd:syscall+0x26e
Jul 15 14:11:40 ymir /netbsd: [ 131.2116186] --- syscall (number 435) ---
Jul 15 14:11:40 ymir /netbsd: [ 131.2216185] netbsd:syscall+0x26e:
Jul 15 14:11:40 ymir /netbsd: [ 131.2216185] cpu0: End traceback...
Jul 15 14:11:40 ymir /netbsd:
Jul 15 14:11:40 ymir /netbsd: [ 131.2216185] dumping to dev 168,2
(offset=8, size=5225879):
Jul 15 14:11:40 ymir /netbsd: [ 131.2216185] dump <5>ktrace timeout
Jul 15 14:11:40 ymir /netbsd: ktrace timeout
Jul 15 14:11:40 ymir /netbsd: [ 131.2216185] ktrace timeout
Jul 15 14:11:40 ymir syslogd[946]: last message repeated 2 times
> Chavdar
>
> On Wed, 20 May 2020 at 22:09, Maxime Villard 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 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:
> > >
> > >
> > >
Re: NVMM not working, NetBSD 9x amd64
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 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 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).
--
Re: NVMM not working, NetBSD 9x amd64
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 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).
Re: NVMM not working, NetBSD 9x amd64
Le 01/05/2020 à 19:13, Chavdar Ivanov a écrit :
On Fri, 1 May 2020 at 13:59, Rhialto 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.
Maxime
Re: NVMM not working, NetBSD 9x amd64
On Fri, 1 May 2020 at 19:11, Rhialto wrote: > > On Fri 01 May 2020 at 18:13:01 +0100, Chavdar Ivanov wrote: > > So far, with several attempts, it works with no problem whatsoever, > > directly booting the newest image on the site pointed above. > > 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. TBH I once fell into the kernel debugger, when starting the Clock app; but twice 'continue' got me out and even the Clock started, so there may be problems, with the emulation or with the image; the software updater starts downloading a bunch of packages, but breaks with mesa. 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. > > -Olaf. > -- > Olaf 'Rhialto' Seibert -- rhialto at falu dot nl > ___ Anyone who is capable of getting themselves made President should on > \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" --
Re: NVMM not working, NetBSD 9x amd64
On Fri 01 May 2020 at 18:13:01 +0100, Chavdar Ivanov wrote: > So far, with several attempts, it works with no problem whatsoever, > directly booting the newest image on the site pointed above. 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. -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
Re: NVMM not working, NetBSD 9x amd64
On Fri, 1 May 2020 at 13:59, Rhialto 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.
>
> 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)
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.
>
> -Olaf.
> --
> Olaf 'Rhialto' Seibert -- rhialto at falu dot nl
> ___ Anyone who is capable of getting themselves made President should on
> \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG"
--
Re: NVMM not working, NetBSD 9x amd64
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.
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)
-Olaf.
--
Olaf 'Rhialto' Seibert -- rhialto at falu dot nl
___ Anyone who is capable of getting themselves made President should on
\X/ no account be allowed to do the job. --Douglas Adams, "THGTTG"
signature.asc
Description: PGP signature
Re: NVMM not working, NetBSD 9x amd64
Hi,
I'm not subscribed to this list but someone forwarded me your email:
> I'm curious about the situation on the NVMM front. On its page it says
> that it works both with Intel and AMD cpu's
> (https://m00nbsd.net/4e0798b7f2620c965d0dd9d6a7a2f296.html), but I've
> read elsewhere
> (https://blog.netbsd.org/tnf/entry/the_hardware_assisted_virtualization_challenge)
> that it only works on AMD - so who is right?
The oldest one is the "wrong" one: the blog post here was written when NVMM had
just been developed, and at first it had only AMD support. Quickly after it
gained Intel support. So now, it has Intel support.
> 1. I tried it on my PC, but it didn't work. My CPU is Intel(R)
> Core(TM)2 Duo CPU T9600, Vt-x enabled.
> First I used the NetBSD 9.0 amd64 release version:
> [...]
> localhost# modload -f nvmm
> modload: nvmm: Not supported
> Apr 25 14:55:11 localhost /netbsd: [ 1781.0615600] [!] No implementation found
> Apr 25 14:55:11 localhost /netbsd: [ 1781.0615600] WARNING: module
> error: built-in module nvmm failed its MODULE_CMD_INIT, error 86
As the message indicates, your CPU is not supported. T9600 is from 2008, and
even though it has VT-x, it probably doesn't have EPT, which means it doesn't
support "real" hardware virtualization. So you cannot use NVMM on your CPU.
There are several hypervisors you also won't be able to use, this CPU is just
too old.
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.
> 2. Also I've got a question about qemu. The 'vanilla' qemu from pkgsrc
> (that is recommended on the m00nbsd page) doesn't know the accelerator
> 'nvmm'.
>
> localhost$ qemu-system-x86_64 -hda ubuntu.qcow -cdrom
> /mnt/ubuntu-16.04.4-desktop-amd64.iso -m 1024M -accel nvmm
> qemu-system-x86_64: -machine accel=nvmm: No accelerator found
>
> Qemu-nvmm is deleted from pkgsrc/wip at the moment:
> https://pkgsrc.se/wip/qemu-nvmm
Maybe you're using an old branch of pkgsrc? The NVMM accelerator is in the
"recent" branches of pkgsrc.
However this won't help you because your CPU is too old.
> 3. Trying the nvmmctl utility ('nvmmctl identify' and 'nvmmctl list')
> results in panic and following reboot after a long count, see
> screenshots for output:
> https://drive.google.com/open?id=1vT0WZbRp8x97qPjGIiNf0GF4PvBezu2H
> https://drive.google.com/open?id=13hl3Z3FMkX6dLZcpL3LXydIMdSqq4qDZ
>
> (Of course 2. and 3. refer to a situation without the nvmm module loaded)
That was a bug, caused by an initialization problem that you managed to
trigger with your configuration. I have now fixed it:
https://mail-index.netbsd.org/source-changes/2020/04/26/msg116701.html
It will be applied to NetBSD-9 soon, so within a few days you should not
have this bug anymore. Thanks for the report!
Maxime
Re: NVMM not working, NetBSD 9x amd64
On my HP Elite laptop with Intel(R) Core(TM) i7-3820QM CPU @ 2.70GHz,
id 0x306a9, it works as good as it can get, I use it constantly.
/dev/nvmm is c 345 0, 640, owner root, group nvmm. The user is also a
member of the nvmm group.
I run it on -current, 9.99.59 at the moment.
The latest versions of emulators/qemu do have the support for nvmm, in
my case qemu-4.2.0nb12.
Performance is quite reasonable as well. The disks I use for all
virtual machines are zfs zvolsn networking is bridged. Typical
invocation command:
Z-fw10p() {
/usr/pkg/bin/qemu-system-x86_64 \
-device qemu-xhci \
-device usb-tablet \
-m 3072M \
-k en-gb \
-accel nvmm \
-vnc :5 \
-drive format=raw,file=/dev/zvol/rdsk/pail/w10 \
-vga vmware \
-net tap,fd=3 3<>/dev/tap0 \
-net nic
}
but I have some server type systems without graphics, e,g, my Xen
Orchestrator machine:
Z-Cxorch() {
/usr/pkg/bin/qemu-system-x86_64 \
-serial mon:stdio \
-nographic \
-m 4096M \
-k en-gb \
-accel nvmm \
-smp 2 \
-drive format=raw,file=/dev/zvol/rdsk/pail/zorch \
-net tap,fd=6 6<>/dev/tap5 \
-net nic
}
Works just fine.
Chavdar
