[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v3 7/7] raspi: add raspberry pi 2 machine
From: |
Peter Crosthwaite |
Subject: |
Re: [Qemu-devel] [PATCH v3 7/7] raspi: add raspberry pi 2 machine |
Date: |
Thu, 14 Jan 2016 15:34:46 -0800 |
On Thu, Jan 14, 2016 at 3:04 PM, Andrew Baumann
<address@hidden> wrote:
> Hi Peter,
>
>> From: Peter Crosthwaite [mailto:address@hidden
>> Sent: Tuesday, 12 January 2016 16:44
>> On Tue, Jan 12, 2016 at 3:53 PM, Andrew Baumann
>> <address@hidden> wrote:
>> >> From: Peter Crosthwaite [mailto:address@hidden
>> >> Sent: Monday, 11 January 2016 19:58
>> >> > + /* Allocate and map RAM */
>> >> > + memory_region_allocate_system_memory(&s->ram,
>> >> OBJECT(machine), "ram",
>> >> > + machine->ram_size);
>> >> > + memory_region_add_subregion_overlap(get_system_memory(), 0,
>> >> &s->ram, 0);
>> >>
>> >> I thought the SoC handled this now? Why do you need to add to
>> >> system_memory?
>> >
>> > If I don't map it here, how do RAM accesses from the CPUs work?
>> >
>>
>> Do the CPUs not have their AS'es connected to your custom ASes by the SoC
>> layer?
>>
>> > Or are you saying that I should still do this, but do it in the SoC not the
>> board level?
>> >
>>
>> I was hoping we could get away with 0 use of system_memory.
>
> On further investigation, I don't think it's possible to wire up CPU ASes
> explicitly. There's no obvious property to set. Each cpu->as is initialised
> to point to address_space_memory at the top of cpu_exec_init(), and there is
> no way I could see to override that.
>
> I think what I have now is pretty clean, but if you'd prefer to do the
> mapping at into the global AS at SoC level that's fine with me too.
>
If it cant be done yet, what is here is a preferable approach. PMM has
some work on list for CPU ASes that may be realted, moreso for the
secure attributes though I think.
Regards,
Peter
> Thanks,
> Andrew