On Sun, Feb 6, 2022 at 11:44 AM Peter Maydell <peter.mayd...@linaro.org> wrote: > > On Sun, 6 Feb 2022 at 09:30, Mark Cave-Ayland > <mark.cave-ayl...@ilande.co.uk> wrote: > > > > On 05/02/2022 15:39, Peter Maydell wrote: > > > The handling of the vram buffer seems weird in this device overall, > > > though -- the memory block is divided into three parts > > > * main vram, one byte per pixel > > > * vram24, four bytes per pixel > > > * cplane, four bytes per pixel > > > > > > As far as I can see, only if depth=24 (fixed at device creation > > > time) do we use the vram24 and cplane parts. But we create the > > > memory block at the same size regardless of depth and we expose > > > the vram24 and cplane parts to the guest as sysbus MMIO regions > > > that are mapped into guest memory regardless of depth... > > > > (goes and looks) > > > > It does look a bit odd certainly. Without Blue Swirl being around all I can > > only > > guess as to why everything is configured to use an alias onto a single VRAM > > memory > > region :/ > > > > As for exposing the vram24 and cplane parts, I don't think it matters since > > 24-bit > > mode is clearly designed to be backwards compatible with 8-bit mode. During > > initialisation OpenBIOS reads the colour depth using the fw_cfg interface > > and adds > > the registers for that mode into the DT as required so the correct > > information is > > exposed to the guest. > > A guest won't notice if we expose stuff to it that it doesn't expect > to be there -- but if the 8-bit-only device is not supposed to have > those memory regions we shouldn't be creating them...
I guess I'll go with your code suggestion as a first step, and we can figure out whether this MR is pointless and remove it later.
