Re: [Qemu-ppc] [v1][PATCH 1/1] PPC: e500: correct params->ram_size with ram_size

[Chen, Tiejun]

> -----Original Message-----
> From: Alexander Graf [mailto:address@hidden 
> Sent: Tuesday, April 30, 2013 5:53 PM
> To: Scott Wood
> Cc: Chen, Tiejun; address@hidden; address@hidden
> Subject: Re: [Qemu-ppc] [v1][PATCH 1/1] PPC: e500: correct 
> params->ram_size with ram_size
> 
> 
> On 29.04.2013, at 21:18, Scott Wood wrote:
> 
> > On 04/28/2013 05:30:09 AM, Tiejun Chen wrote:
> >> We should sync params->ram_size after we fixup memory size on a 
> >> alignment boundary. Otherwise Guest would exceed the actual memory 
> >> region.
> >> Signed-off-by: Tiejun Chen <address@hidden>
> >> ---
> >> hw/ppc/e500.c |    2 ++
> >> 1 file changed, 2 insertions(+)
> >> diff --git a/hw/ppc/e500.c b/hw/ppc/e500.c index c1bdb6b..145da0e 
> >> 100644
> >> --- a/hw/ppc/e500.c
> >> +++ b/hw/ppc/e500.c
> >> @@ -523,6 +523,8 @@ void ppce500_init(PPCE500Params *params)
> >>     /* Fixup Memory size on a alignment boundary */
> >>     ram_size &= ~(RAM_SIZES_ALIGN - 1);
> >> +    /* Sync this for the system. */
> >> +    params->ram_size = ram_size;
> > 
> > Could you explain this further?  When does params->ram_size 
> ever get used after this point?
> 
> This is the respective code in vl.c:
> 
> >     QEMUMachineInitArgs args = { .ram_size = ram_size,
> >                                  .boot_device = 
> (boot_devices[0] == '\0') ?
> >                                                 
> machine->boot_order :
> >                                                 boot_devices,
> >                                  .kernel_filename = kernel_filename,
> >                                  .kernel_cmdline = kernel_cmdline,
> >                                  .initrd_filename = initrd_filename,
> >                                  .cpu_model = cpu_model };
> >     machine->init(&args);
> 
> 
> After this, args in unused. So as you can see, 
> params->ram_size never gets used after it's read once.
> 
> What bug are you trying to fix? Maybe there really is 

I had an explanation when I reply to Scott, could you take a look at that?

If you have no further objection, I'd like to send next version with 
withdrawing that comment as Scott suggest.

Tiejun