* Cédric Le Goater (c...@kaod.org) wrote: > On 1/17/22 06:52, David Gibson wrote: > > On Fri, Jan 14, 2022 at 08:07:21AM +0100, Cédric le Goater wrote: > > > On 1/14/22 00:41, David Gibson wrote: > > > > On Thu, Jan 13, 2022 at 06:51:56PM +0000, Dr. David Alan Gilbert wrote: > > > > > Hi, > > > > > Is there any easy way of getting a machine where the pbr403 > > > > > vmstate > > > > > would be generated? > > > > > > > > The condition in pbr403_needed is... > > > > > > > > return (pvr & 0xffff0000) == 0x00200000; > > > > > > > > .. which looks to be the PVR for ppc403 models. That makes sense with > > > > the section name... but not so much with the fact that it's under > > > > cpu/tlb6xx. The 6xx MMU is basically unrelated to the 40x MMU. But > > > > it looks like the vmstate_tlbemb might be shared between then, because > > > > of bad ideas of the past. > > > > > > > > But in any case, we already dropped what little 403 support we ever > > > > had - there's nothing with that PVR even listed in > > > > target/ppc/cpu-models.h. > > > > > > > > So I think we should just drop it. > > > > > > yes. But we can not remove env.pb since this would break migration > > > compatibility, correct ? > > > > Only if it appears in a migration section that's actually emitted by a > > supported machine type. As far as I can tell the only section that > > does that is vmstate_pbr403, which we're also dropping so we should be > > fine. > > I sent a patch to remove vmstate_pbr403 first.
Thanks! Dave > > It is also touched in the *super* old cpu_load_old. I suspect we > > could probably just drop that completely, since I don't think we > > realistically support migration from a version that old anyway. But > > even if we don't want to do that right now, we can just replace the > > reads into env->pb with discarding reads and we'll be fine. We don't > > implement any cpus that actually used those fields, so we can ignore > > them in the migration stream. > > I will take a look at this also with follow ups. > > Thanks, > > C. > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
