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: Martin Husemann <martin%duskware.de@localhost>, Christoph Badura <bad%bsd.de@localhost>,
 oskar%fessel.org@localhost, gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/58681
Date: Thu, 24 Jul 2025 10:50:32 -0600

 On 4/18/25 01:52, Martin Husemann wrote:
 > My "issues" were basically: there is a hard coded little endian in there
 > and that always triggers me (as a mostly big endian guy) - is that needed
 > here and correct, or just because we do not yet have any supervisor/guest
 > arch combination where that driver would use big endian?
 
 Some parts of the virtio spec explicitly require little-endian values
 if that is what you are referring to:
 
 https://docs.oasis-open.org/virtio/virtio/v1.1/virtio-v1.1.html
 
 Please let me know if there is any endian-specific code not dictated by
 this that I have missed.
 
 I have tested this driver on big-endian sparc64 as described above.
 
 > The other point is a pure gut feeling that the local copy of a shadow
 > frame buffer in this code should not really be needed and we ought to
 > attach to vcons(9) or whatever and re-use slightly more code from there,
 > but that is hard to say as I have never looked closer into the vcons
 > code nor fully understand the requirements of this virtio driver.
 
 If the shadow framebuffer you are referring to is the buffer that
 is pointed to by sc_fb_dma_kva, that is the main framebuffer itself.
 The virtio GPU device is directly passed the translated address in main
 memory of this framebuffer, which the hypervisor then copies from. The
 driver arranges for rasops to manipulate the contents of this
 framebuffer directly. I would appreciate any suggestions for a more
 direct or efficient way for this to work if you would know of one.
 
 Regards,
     George