On 17/11/2014 21:08, Michael S. Tsirkin wrote: > Add API to manage on-device RAM. > This looks just like regular RAM from migration POV, > but has two special properties internally: > > - block is sized on migration, making it easier to extend > without breaking migration compatibility or wasting > virtual memory > - callers must specify an upper bound on size
Why should on-device RAM have this property, or why should this property be interesting for on-device RAM (as opposed to generic "we are using MemoryRegions internally and we want them resized")? I admit the patches look clean, but I would prefer to have some changes to the API and I dislike introducing a worse API just because we are so close to release. For example, the resized callback should probably receive a MemoryRegion, not a host/length pair, or even better there could be a NotifierList per RAMBlock. Also, I am afraid that this design could make it easier to introduce backwards-incompatible changes. I very much prefer to have user-controlled ACPI information (coming from the command-line) byte-for-byte identical for a given machine type. Patches for that have been on the list for almost two months, and it's not nice. Paolo
