Re: [PATCH v5 1/8] hw/display/{cg3.tcx}: Do not use memory_region_init_rom_nomigrate()

[Peter Xu <peterx@redhat.com>]

On Thu, Mar 05, 2026 at 11:15:59AM +0000, Mark Cave-Ayland wrote:
> On 03/03/2026 09:51, Peter Maydell wrote:
> 
> > On Sun, 1 Mar 2026 at 21:03, BALATON Zoltan <balaton@eik.bme.hu> wrote:
> > > 
> > > Use memory_region_init_rom() instead which is what other devices do.
> > > This is breaks migration but these devices are only used on sparc Sun
> > > machines which have no migration compatibility guarantee.
> > > 
> > > Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
> > > ---
> > >   hw/display/cg3.c | 5 ++---
> > >   hw/display/tcx.c | 5 ++---
> > >   2 files changed, 4 insertions(+), 6 deletions(-)
> > 
> > Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
> > 
> > I think the compat break on these machines is worth it
> > to make progress on the cleanup of these functions.
> 
> Hi Peter,

Hi, Mark,

[some pure thoughts before PeterM chimes in..]

> 
> From what I can see there is still on-going discussion on this series,
> however if the general consensus is that the removal of the last of these
> legacy functions is now imminent then I won't object if you want to merge
> this.

In this case it's not easy to reach a consensus collecting "yes"s but
"no"s, that who still prefer this ABI to be kept.

Personally, I would respect your opinion, and I queued them because from
what I read the impact seems under control, please correct me otherwise.

There's indeed the dilemma that since sparc machines are not versioned,
then it's easier to be treated as a system that may not demand the highest
level of ABI guarantees.

It's also harder to consider ABI compatibility for un-versioned machs
comparing to versioned.

It's because for other versioned machines, we have the ~6 years lifespan
nowadays for them so we can drop old things over specific period of time.
While when a machine is not versioned, it's almost impossible to mark the
time of deprecation.

We either need to choose to maintain ABI for those machines forever, or we
allow ABI break to some degree.  When a machine is not versioned, it's
harder to justify we maintain these machines' ABI even longer than
versioned machines (which we deemed to be "relatively serious" users).

So if we want to stick with that machine versioning plan, maybe we should
start version machines that we may care on ABIs.  IIUC it doesn't need to
introduce one machine type every release, however when versioned we will be
able to follow the same ~6 years obsoletion phase at least.

Thanks,

-- 
Peter Xu