qemu-system-x86_64: invalid accelerator nvmm. Is this a bug ?
Mario Marietto
marietto2008 at gmail.com
Fri Dec 31 17:37:43 PST 2021
I want also to inform you that any attempt to send a bug to :
bugs at dragonflybsd.org
ends with this error message :
This is the mail system at host leaf.dragonflybsd.org.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can
delete your own text from the attached returned message.
The mail system
<redmine-bugs at leaf.dragonflybsd.org>: Command time limit exceeded: "exec
/usr/local/bin/procmail /home/bugtracker/redmine-bugs/.procmailrc".
Command
output: procmail: Couldn't determine implicit lockfile from
"/home/bugtracker/redmine-mail.sh"
/usr/local/lib/ruby/2.7/net/protocol.rb:44:in `connect_nonblock':
SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B:
certificate verify failed (certificate has expired)
(OpenSSL::SSL::SSLError) from
/usr/local/lib/ruby/2.7/net/protocol.rb:44:in `ssl_socket_connect' from
/usr/local/lib/ruby/2.7/net/http.rb:1009:in `connect' from
/usr/local/lib/ruby/2.7/net/http.rb:943:in `do_start' from
/usr/local/lib/ruby/2.7/net/http.rb:932:in `start' from
/home/bugtracker/redmine/extra/mail_handler/rdm-mailhandler.rb:41:in
`post_form' from
/home/bugtracker/redmine/extra/mail_handler/rdm-mailhandler.rb:168:in
`submit' from
/home/bugtracker/redmine/extra/mail_handler/rdm-mailhandler.rb:215:in
`<main>'
Il giorno sab 1 gen 2022 alle ore 02:32 Mario Marietto <
marietto2008 at gmail.com> ha scritto:
> Yeah,I tried to join the IRC channel several times,but after some hours I
> left the channel because no one gave support. It seemed to me that the
> channel was full of bot and not humans. Anyway,I posted the question on
> different channels,such as ML and Reddit,but in all these cases,I didn't
> get some support,I should be honest. There is an update for this problem.
> I've got qemu from here : fetch
> https://leaf.dragonflybsd.org/~aly/nvmm/qemu-6.0.0_1.txz
>
> and I tried again :
>
> /home/marietto/Desktop/Files/DFLY/qemu-6.0.0_1/usr/local/bin/./qemu-system-x86_64
> \
> -machine type=q35,accel=nvmm \
> -smp cpus=4 -m 8G \
> -drive
> if=pflash,format=raw,readonly=on,file=/usr/local/share/uefi-edk2-qemu/QEMU_UEFI_CODE-x86_64.fd
> \
> -drive
> if=pflash,format=raw,file=/usr/local/share/uefi-edk2-qemu/QEMU_UEFI_VARS-x86_64.fd
> \
> -drive
> file=/mnt/dragonfly-ufs/bhyve/impish-cuda-11-4-nvidia-470.img,if=none,id=disk0
> \
> -device virtio-blk-pci,drive=disk0 \
> -netdev user,id=net0,hostfwd=tcp:127.0.0.1:6022-:22 \
> -device virtio-net-pci,netdev=net0 \
> -object rng-random,id=rng0,filename=/dev/urandom \
> -device virtio-rng-pci,rng=rng0 \
> -display curses \
>
> but I've got this output :
>
> qemu-system-x86_64: NVMM: Mem Assist Failed [gpa=0xfffffff0]
> qemu-system-x86_64: NVMM: Failed to execute a VCPU.
> Abort trap (core dumped)
> VGA Blank mode
>
> Il giorno sab 1 gen 2022 alle ore 00:54 Aaron LI <aly at aaronly.me> ha
> scritto:
>
>> Hi Mario,
>>
>> On Dec 31, 2021, at 23:51, Mario Marietto <marietto2008 at gmail.com> wrote:
>>
>> Hello.
>>
>> For sure I don't want to bother you,but after having posted this question
>> in several places and no one replied (like IRC,the ML,or Reddit or the
>> UnitedBSD forum),
>>
>> I didn’t seem to see this question on the #dragonflybsd IRC and this
>> mailing list.
>>
>> I've thought of trying this unorthodox method,just because...I need
>> support to understand the reasons for this error. I also think that by
>> helping me,you are also helping the other DFLY lovers. Thanks for the
>> understanding. Taking in consideration that NVMM has been ported from
>> NetBSD and on the NetBSD this same error has been fixed,as you can see
>> below :
>>
>> http://mail-index.netbsd.org/pkgsrc-users/2021/09/05/msg034346.html
>>
>> it seems that the fix has not been ported to DFLY,so for this reason we
>> can't use NVMM.
>>
>> Sure. I noticed such a fix to Qemu upstream some time ago.
>>
>> But well, we can’t directly use the official unmodified version. The
>> DPorts version should be used and there are several necessary patches
>> (ideally we’d better push to upstream, but that takes time and efforts).
>>
>> It looks to me you were using the Qemu build from upstream rather than
>> installed via pkg(8). If yes, then that’s the issue, and you just switch to
>> our version and should just work.
>>
>> Check:
>> https://www.dragonflybsd.org/docs/docs/howtos/nvmm/
>>
>> So,this is what I did :
>>
>> I'm trying to test qemu and nvmm on :
>>
>> DragonFly marietto 6.1-DEVELOPMENT DragonFly
>> v6.1.0.573.gfca8e8-DEVELOPMENT #0: Wed Dec 22 09:11:32 CET 2021
>> marietto at marietto:/usr/obj/usr/src/sys/X86_64_GENERIC x86_64
>>
>> first of all I added these users on the nvmm group :
>>
>> root at marietto:/home/marietto # pw groupmod nvmm -m marietto
>> root at marietto:/home/marietto # pw groupmod nvmm -m root
>>
>> then,I've launched this vm :
>>
>> qemu-system-x86_64 \
>> -machine type=q35,accel=nvmm \
>> -smp cpus=4 -m 8G \
>> -drive if=pflash,format=raw,readonly=on,file=/usr/local/share/uefi-edk2-qemu/QEMU_UEFI_CODE-x86_64.fd \
>> -drive if=pflash,format=raw,file=/usr/local/share/uefi-edk2-qemu/QEMU_UEFI_VARS-x86_64.fd \
>> -drive file=/mnt/dragonfly-ufs/bhyve/impish-cuda-11-4-nvidia-470.img,if=none,id=disk0 \
>> -device virtio-blk-pci,drive=disk0 \
>> -netdev user,id=net0,hostfwd=tcp:127.0.0.1:6022-:22 \
>> -device virtio-net-pci,netdev=net0 \
>> -object rng-random,id=rng0,filename=/dev/urandom \
>> -device virtio-rng-pci,rng=rng0 \
>> -display curses \
>>
>> WARNING: Image format was not specified for '/mnt/dragonfly-ufs/bhyve/impish-cuda-11-4-nvidia-470.img' and probing guessed raw. Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted. Specify the 'raw' format explicitly to remove the restrictions.
>>
>> unfortunately I get this error,that it seems a bug to me :
>>
>> qemu-system-x86_64: invalid accelerator nvmm
>>
>> just because nvmm works great :
>>
>> root at marietto:/home/marietto/Desktop # nvmmctl identify
>> nvmm: Kernel API version 3nvmm: State size 1008nvmm: Comm size 4096nvmm: Max machines 128nvmm: Max VCPUs per machine 128nvmm: Max RAM per machine 127Tnvmm: Arch Mach conf 0nvmm: Arch VCPU conf 0x3<CPUID,TPR>nvmm: Guest FPU states 0x3<x87,SSE>
>>
>> The NVMM part looks good.
>>
>> Cheers,
>> Aaron
>>
>
>
> --
> Mario.
>
--
Mario.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/users/attachments/20220101/f8dbb79b/attachment-0003.htm>
More information about the Users
mailing list