On Thu, Dec 20, 2018 at 03:21:17PM +0000, Julien Grall wrote: > At the moment, a user is only able to specify the amount of RAM used by the > guest. Where the RAM will live is left to the software and hardcoded. > > It could be useful for testing purpose to move the RAM in different place. > This series adds the possibility for the user to specify multiple RAM region. > > The option -m/--mem is extended to specify the address using the following > format: <size>@<addr>. The option needs to be repeated as many times as the > number of RAM region in the guest layout. > > For instance, if you want 512MB at 3GB and 512MB 4GB it would look like: > -m 512@0xc0000000 -m 512@0x100000000 > > Note that the memory layout is not yet fully configurable by the user, so the > MMIO region is still living below 2GB. This means RAM cannot live in the > region 0-2GB. This could be changed in the future. Although the implementation mostly looks ok (I've commented on some things I spotted), I'm not completely sold on the need for this. What sort of testing do you have in mind that requires multiple memory banks to be specified at runtime? I'm keen to keep kvmtool as simple and lean as we can, whilst supporting enough functionality to be useful as a prototyping tool for the latest KVM features. I'm just struggling to see how support for multiple memory banks really fits in with that, and whether or not we can't just make it easier to configure this at compile time instead. Finally, your series also seems to duplicate the memory bank information in three places: * struct kvm.ram[] * struct kvm.mem_banks * struct kvm_config.ram[] and these aren't used consistently between functions. If we do go ahead with this, I think this needs consolidating so that e.g. the mem_banks are authoritative (but I appreciate that you've just extended what we had already). Will
