>> Problem David tries to solve is that > > Uh, which David? I assume he was referring to you :)
> >> 1: user hotplugged backend with wrong page size >> 2: hotplug of associated device 'pc-dimm' cleanly fails with error >> 3: guest does reboot and QEMU crashes with fatal error >> >> Issue is that qemu_getmaxrampagesize() iterates over backends which >> might be used for guest RAM or theoretically might be used for >> something else. >> >> using 'mapped' attribute is a hack that currently works around issue [3] >> but it's prone to being incorrect depending on call order. > > I'm not sure what you mean by that. For the purposes we need on ppc > checking the RAM that's actually present in the guest really is what > we need. I guess one issue is that memory backends might actually be used for something else than RAM. As of now, you can't differentiate between RAM and *something else* when looking at a mapped memory backend. E.g. internal memory devices could solve that in the future. Iterating over them, looking at the memory region, detecting the page size might be easy and you can be sure it is RAM. Then, we would have to change/simplify the implementation of qemu_getrampagesize() and friends. > >> maybe we should prevent [1] in the first place (but making backends >> depend on machine/accel doesn't look good either)? > > Yeah, I wondered about this. There's no way to do it right now, and a > hook would be kinda ugly. Not sure if it's more or less ugly than the > alternatives. > -- Thanks, David / dhildenb
