Re: [Qemu-devel] [PATCH v2 1/4] xilinx_zynq: added smp support

[Peter Crosthwaite]

On Tue, Oct 9, 2012 at 9:52 PM, Peter Maydell <address@hidden> wrote:
> On 4 October 2012 01:16, Peter Crosthwaite
> <address@hidden> wrote:
>> From: Peter A. G. Crosthwaite <address@hidden>
>>
>> Added linux smp support for the xilinx zynq platform (2x cpus are supported)
>>
>> Signed-off-by: Peter A. G. Crosthwaite <address@hidden>
>> ---
>> Changed from v1:
>> Addressed PMM review
>> Shorted secondary bootloop using MVN instruction.
>> Used default reset secondary instead of custom one.
>> Rebased against QOM cpu developments.
>> Few whitespace fixes.
>>
>>  hw/xilinx_zynq.c |   57 
>> ++++++++++++++++++++++++++++++++++++++++++-----------
>>  1 files changed, 45 insertions(+), 12 deletions(-)
>>
>> diff --git a/hw/xilinx_zynq.c b/hw/xilinx_zynq.c
>> index 7e6c273..22a2bc5 100644
>> --- a/hw/xilinx_zynq.c
>> +++ b/hw/xilinx_zynq.c
>> @@ -30,6 +30,32 @@
>>
>>  #define IRQ_OFFSET 32 /* pic interrupts start from index 32 */
>>
>> +#define SMP_BOOT_ADDR 0x0fff0000
>
> What is at this address in real hardware? I can't see anything in the
> machine model that maps at this address but I could be missing it.
> (Generally we put the secondary bootloader in some place corresponding
> to some kind of real RAM.)
>

Main RAM (based at 0). We always pass -M big enough for this to not be
a problem. I guess we could force to ram big enough in the machine
model to catch the case where memory is too small.

>> +#define SMP_BOOTREG_ADDR 0xfffffff0
>
> ...this is an address in the on-chip memory, right?
>

Yes, Our bootrom does something similar for secondary CPU kicking, so
we chose that address to bring the machine as close to the actual boot
process as possible.

Regards,
Peter

> Other than those queries, patch looks OK.
>
> -- PMM