On 20.02.2018 12:18, Christian Borntraeger wrote: > Given that we have trouble modeling this properly I somewhat like the idea. > We should have never folded this into the common code memory hotplug > infrastructure as it is different. Instead we really should have provided > a different interface and we should have build it with migration support. > > If we need it again in the future, we can certainly add it back via an > s390 specific interface. >
Thinking out load (stuff we could to in the future): We could model ordinary memory (-m XG) using standby memory. But instead of creating and deleting memory regions, work on a single huge one (just as now). (using compat machines to control behavior) What would be the optimization? When the guest tells us to unassign memory, we can simply madv(free) that memory. That means if the guest unplugs(offlines) memory, we can actually free the backing storage. This way it acts somewhat like a balloon - but also gets rid of struct pages in the guest. Of course, this would still not be real memory hot(un)plug, as there is no way to control it from the outside. Just a possible optimization. -- Thanks, David / dhildenb
