Re: kern/58681

["George Matsumura via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR kern/58681; it has been noted by GNATS.

From: George Matsumura <gorg%gorgnet.net@localhost>
To: gnats-bugs%netbsd.org@localhost, bad%bsd.de@localhost
Cc: oskar%fessel.org@localhost, Martin Husemann <martin%duskware.de@localhost>
Subject: Re: kern/58681
Date: Thu, 24 Jul 2025 10:41:26 -0600

 I apologize for the late reply.
 
 On Fri, 18 Apr 2025 10:11:47 +0200
 Christoph Badura <bad%bsd.de@localhost> wrote:
 > I was hoping you had some instructions to use this under QEMU so we could
 > test locally without going to the trouble of having to setup and account and
 > a VM with netcup/hetzner.  Which server types specifically was this tested
 > with?  Are there ones where it's applicable but known not to work?
 
 Certainly, I used the following with QEMU:
 
 qemu-system-aarch64 -M virt -cpu neoverse-n1 ... \
     -device virtio-gpu -display sdl \
     ...
 
 I used a CAX11 VPS from Hetzner for testing as well.
 
 > Hmm, skimming the code and the QEMU virtio-gpu docs, I guess this only supports> "-device virtio-gpu" and none of the other virtio-gpu options.  Which
 > backends though?
 
 The purpose of this driver is simply to provide an output for wscons
 and only the 2D backend is supported.
 
 > Does this work on Intel CPUs too?  Or was this tested only with the ARM VPS.
 
 I used the following for testing the driver on amd64 under QEMU:
 
 qemu-system-x86_64 ... \
     -vga none -serial stdio -device virtio-gpu -display sdl \
     -usb -device usb-kbd \
     ...
 
 I was also able to test this driver under big-endian sparc64 with QEMU:
 
 qemu-system-sparc64 -M sun4u ... \
     -device virtio-gpu,bus=pciB -display sdl \
     ...
 
 > > https://marc.info/?l=openbsd-cvs&m=173473291202696
 > 
 > Reading the commit message, this sounds useful to have and the right thing
 > to do.  Do you think this could be easily ported to NetBSD?  I haven't
 > looked at our source code.
 
 I apologize, what I meant to say is that the problem mentioned in this
 commit is already not an issue due to how NetBSD's
 virtio_child_attach_finish is already responsible for queue setup and
 uses the correct order.
 
 > We should do a little bit of code review.  From skimming over the patch I'd
 > like to see two improvements:
 > 
 > 1. the man page should be specific about which (QEMU) backends and
 > interfaces the driver supports.
 > 
 > 2. I'd like to see a comment what fields in the softc are protected by
 > sc_mutex and what the locking protocol is.
 
 In the updated patch I should send soon, I have added a comment and
 updated the man page to attempt to address this. Please indicate if it
 is sufficient.
 
 > Unrelated to this being integrated:  It would help us a lot if you were
 > interested in long term maintenance of the driver.  I.e. monitoring work on
 > the OpenBSD version and incorporating it if desirable.  And monitoring our
 > mailing lists and GNATS to address bugs and give users support, if
 > necessary.
 
 I would be more than happy to try, although I cannot guarantee my
 reliability. If my response time to your message is any indication, it
 seems likely I may be a poor maintainer despite my best intentions. Is
 there any particular mailing list or lists I should be subscribed to in
 order to effectively act as a maintainer for this driver?
 
 Thank you again for reviewing this.
 
 Regards,
     George