On 3/8/22 10:56, Thomas Zimmermann wrote:

Hi

Am 08.03.22 um 10:31 schrieb Javier Martinez Canillas:

quoted

On 3/3/22 21:58, Thomas Zimmermann wrote:

quoted

Don't select shadow buffering for the fbdev console explicitly. The
fbdev emulation's heuristic will enable it for any framebuffer with
.dirty callback.

Indeed it does. Not related to your series but looking at this
patch I noticed that drivers/gpu/drm/tiny/bochs.c will be the
only driver that sets .prefer_shadow_fbdev after this lands.

The driver is using GEM so I wonder if after your series this
DRM driver could have a .dirty callback and the field just be
dropped? Or there would still be a case where it is needed ?

Bochs uses VRAM helpers (i.e., TTM). Fbdev and userspace would directly 
write into that buffer memory without a copy. So the dirty function 
would be empty.

Other drivers with VRAM helpers (e.g., hibmc, ast) operate on uncached 
I/O memory AFAICT. So they set .prefer_shadow, which also affects 
userspace. Bochs uses cached memory and shouldn't need prefer_shadow. 
Setting prefer_shadow_fbdev is only there for making the fbdev buffer 
object evictable from video memory.

As it stands, using prefer_shadow_fbdev is the cleanest solution, even 
if bochs is the only user of that field.

Alternatively, we could make it a requirement that qemu provides enough 
video memory for bochs to unconditionally pin the fbdev BO there without 
ever evicting. I guess, that would mean 32 MiB of VRAM at least.

I see. Thanks a lot for this explanation.
 

Best regards
Thomas

-- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat