Re: [Qemu-devel] [PATCH 0/2] Let boards state maximum RAM limits in QEMUMachine struct
On 26 March 2011 11:41, Blue Swirl blauwir...@gmail.com wrote: On Mon, Mar 21, 2011 at 7:47 PM, Peter Maydell peter.mayd...@linaro.org wrote: This fairly simple patchset adds a new 'max_ram' field to the QEMUMachine structure so that a board model can specify the maximum RAM it will accept. We can then produce a friendly diagnostic message when the user tries to start qemu with a '-m' option asking for more RAM than that. (Currently most of the ARM devboard models respond with an obscure guest crash when the guest tries to access RAM and finds device registers instead.) This could replace the field max_mem in hwdef structures in sun4m.c. I've had a go at this, and it's revealed a flaw in this patchset, which is that the max_ram field needs to be type target_physaddr_t rather than ram_addr_t. I'll post another patchset including a sun4m cleanup(*) once I've done some testing on it. (*) includes combining the QEMUMachine struct into the sun4*_hwdef struct, which is necessary so the init fn can get at it and also I think neater. -- PMM
Re: [Qemu-devel] [PATCH 0/2] Let boards state maximum RAM limits in QEMUMachine struct
On Mon, Mar 21, 2011 at 7:47 PM, Peter Maydell peter.mayd...@linaro.org wrote: This fairly simple patchset adds a new 'max_ram' field to the QEMUMachine structure so that a board model can specify the maximum RAM it will accept. We can then produce a friendly diagnostic message when the user tries to start qemu with a '-m' option asking for more RAM than that. (Currently most of the ARM devboard models respond with an obscure guest crash when the guest tries to access RAM and finds device registers instead.) If no maximum size is specified we default to the old behaviour of do not impose any limit. The advantage of doing this in vl.c rather than in each board (apart from avoiding code duplication) is that we can distinguish between the user asked for more RAM than we support (an error) and the global default RAM size is more than our maximum (just cap the RAM size to the board maximum). This could replace the field max_mem in hwdef structures in sun4m.c. Another candidate for refactoring would be default_cpu_model.
[Qemu-devel] [PATCH 0/2] Let boards state maximum RAM limits in QEMUMachine struct
This fairly simple patchset adds a new 'max_ram' field to the QEMUMachine structure so that a board model can specify the maximum RAM it will accept. We can then produce a friendly diagnostic message when the user tries to start qemu with a '-m' option asking for more RAM than that. (Currently most of the ARM devboard models respond with an obscure guest crash when the guest tries to access RAM and finds device registers instead.) If no maximum size is specified we default to the old behaviour of do not impose any limit. The advantage of doing this in vl.c rather than in each board (apart from avoiding code duplication) is that we can distinguish between the user asked for more RAM than we support (an error) and the global default RAM size is more than our maximum (just cap the RAM size to the board maximum). I did think about also adding a default_ram field so each board could default to the same amount of RAM that real hardware has, but since we allocate RAM up front rather than only when accessed, this would push the initial default allocated RAM size up from 128MB to 1GB on models like the PBX A9, and it didn't seem very friendly to do that. I'm happy to be persuaded back again, though :-) This patchset was prompted by bugs like: https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/584480 https://bugs.launchpad.net/ubuntu/+source/rootstock/+bug/570588 Peter Maydell (2): Allow boards to specify maximum RAM size hw: Add maximum RAM specifications for ARM devboard models hw/boards.h |1 + hw/integratorcp.c |1 + hw/realview.c | 11 +++ hw/versatilepb.c |5 + vl.c | 16 +++- 5 files changed, 33 insertions(+), 1 deletions(-)
Re: [Qemu-devel] [PATCH 0/2] Let boards state maximum RAM limits in QEMUMachine struct
On 03/21/2011 12:47 PM, Peter Maydell wrote: This fairly simple patchset adds a new 'max_ram' field to the QEMUMachine structure so that a board model can specify the maximum RAM it will accept. We can then produce a friendly diagnostic message when the user tries to start qemu with a '-m' option asking for more RAM than that. (Currently most of the ARM devboard models respond with an obscure guest crash when the guest tries to access RAM and finds device registers instead.) If no maximum size is specified we default to the old behaviour of do not impose any limit. The advantage of doing this in vl.c rather than in each board (apart from avoiding code duplication) is that we can distinguish between the user asked for more RAM than we support (an error) and the global default RAM size is more than our maximum (just cap the RAM size to the board maximum). I did think about also adding a default_ram field so each board could default to the same amount of RAM that real hardware has, but since we allocate RAM up front rather than only when accessed, this would push the initial default allocated RAM size up from 128MB to 1GB on models like the PBX A9, and it didn't seem very friendly to do that. I'm happy to be persuaded back again, though :-) I don't have any objections to these patches, but it makes me wonder if we should try to go further. There are certainly a lot of use-cases where the boards being emulated are extremely sensitive to the options specified. I wonder if we ought to provide a better way for boards to participate in command line validation. For instance, I know that many boards can only accept certain RAM sizes that map to realistic DIMM sizes. I don't have any great ideas here but wonder if it's something we should more seriously consider. Regards, Anthony Liguori This patchset was prompted by bugs like: https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/584480 https://bugs.launchpad.net/ubuntu/+source/rootstock/+bug/570588 Peter Maydell (2): Allow boards to specify maximum RAM size hw: Add maximum RAM specifications for ARM devboard models hw/boards.h |1 + hw/integratorcp.c |1 + hw/realview.c | 11 +++ hw/versatilepb.c |5 + vl.c | 16 +++- 5 files changed, 33 insertions(+), 1 deletions(-)
Re: [Qemu-devel] [PATCH 0/2] Let boards state maximum RAM limits in QEMUMachine struct
On Tue, 22 Mar 2011 04:47:18 am Peter Maydell wrote: This fairly simple patchset adds a new 'max_ram' field to the QEMUMachine structure so that a board model can specify the maximum RAM it will accept. We can then produce a friendly diagnostic message when the user tries to start qemu with a '-m' option asking for more RAM than that. (Currently most of the ARM devboard models respond with an obscure guest crash when the guest tries to access RAM and finds device registers instead.) As a user, I've been bitten by this. Without understanding how qemu works, the problem is quite surprising: all I've done is increased the RAM, and now it just crashes. I don't think my review of the code will count for much, and I'd prefer to see the code added rather than not, but you could move the cmd.c macros (MEGABYTES and TO_MEGABYTES) to some common header and just use those. They are pretty ugly though... Brad
