qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 4/4] ppc/pnv: Add xscom- prefix to pervasive-control region n


From: Peter Xu
Subject: Re: [PATCH 4/4] ppc/pnv: Add xscom- prefix to pervasive-control region name
Date: Tue, 26 Nov 2024 10:43:55 -0500

On Tue, Nov 26, 2024 at 06:19:52AM +0100, Philippe Mathieu-Daudé wrote:
> On 26/11/24 04:54, Nicholas Piggin wrote:
> > On Tue Nov 26, 2024 at 5:28 AM AEST, Philippe Mathieu-Daudé wrote:
> > > Hi,
> > > 
> > > On 25/11/24 14:20, Nicholas Piggin wrote:
> > > > By convention, xscom regions get a xscom- prefix.
> > > > 
> > > > Fixes: 1adf24708bf7 ("hw/ppc: Add pnv nest pervasive common chiplet 
> > > > model")
> > > > Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> > > > ---
> > > >    hw/ppc/pnv_nest_pervasive.c | 2 +-
> > > >    1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 
> > > > diff --git a/hw/ppc/pnv_nest_pervasive.c b/hw/ppc/pnv_nest_pervasive.c
> > > > index 77476753a4..780fa69dde 100644
> > > > --- a/hw/ppc/pnv_nest_pervasive.c
> > > > +++ b/hw/ppc/pnv_nest_pervasive.c
> > > > @@ -177,7 +177,7 @@ static void pnv_nest_pervasive_realize(DeviceState 
> > > > *dev, Error **errp)
> > > >        pnv_xscom_region_init(&nest_pervasive->xscom_ctrl_regs_mr,
> > > >                              OBJECT(nest_pervasive),
> > > >                              &pnv_nest_pervasive_control_xscom_ops,
> > > > -                          nest_pervasive, "pervasive-control",
> > > > +                          nest_pervasive, "xscom-pervasive-control",
> > > 
> > > Could this break migration stream? Or only RAM regions need to
> > > have a stable name? I don't remember, but try be be cautions with
> > > such cosmetic change just before the release ;)
> > 
> > Hey Phil,
> > 
> > Thanks for always somehow being across everything :)
> 
> ;)
> 
> Answering myself, I/O regions are migrated within the device state,
> per field, via DeviceClass::vmsd structure.

IIUC by default we don't migrate IO regions at all, unless we register
something into the VMSD explicitly.

> 
> IIRC RAM regions are the ones tied to their name, which is built
> using the object owner, which is why we can't change migrated RAM
> MR owners.

True.

Thanks,

-- 
Peter Xu




reply via email to

[Prev in Thread] Current Thread [Next in Thread]