Re: [Qemu-devel] [RFC PATCH 0/8] Towards an Heterogeneous QEMU

[Peter Crosthwaite]

On Mon, Oct 26, 2015 at 10:12 AM, mar.krzeminski
<address@hidden> wrote:
>
>
> W dniu 25.10.2015 o 22:38, Peter Crosthwaite pisze:
>>
>> On Thu, Oct 22, 2015 at 2:21 AM, Christian Pinto
>> <address@hidden> wrote:
>>>
>>> Hello Peter,
>>>
>>>
>>> On 07/10/2015 17:48, Peter Crosthwaite wrote:
>>>>
>>>> On Mon, Oct 5, 2015 at 8:50 AM, Christian Pinto
>>>> <address@hidden> wrote:
>>>>>
>>>>> Hello Peter,
>>>>>
>>>>> thanks for your comments
>>>>>
>>>>> On 01/10/2015 18:26, Peter Crosthwaite wrote:
>>>>>>
>>>>>> On Tue, Sep 29, 2015 at 6:57 AM, Christian Pinto
>>>>>> <address@hidden>  wrote:
>>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> This RFC patch-series introduces the set of changes enabling the
>>>>>>> architectural elements to model the architecture presented in a
>>>>>>> previous
>>>>>>> RFC
>>>>>>> letter: "[Qemu-devel][RFC] Towards an Heterogeneous QEMU".
>
> Sorry for late response, unfortunately my M3+A9 SoC can not be published
> (yet).
> But I am working on it.
>>>>>>>
>>>>>>> and the OS binary image needs
>>>>>>> to be placed in memory at model startup.
>>>>>>>
>>>>>> I don't see what this limitation is exactly. Can you explain more? I
>>>>>> do see a need to work on the ARM bootloader for AMP flows, it is a
>>>>>> pure SMP bootloader than assumes total control.
>>>>>
>>>>> the problem here was to me that when we launch QEMU a binary needs to
>>>>> be
>>>>> provided and put in memory
>>>>> in order to be executed. In this patch series the slave doesn't have a
>>>>> proper memory allocated when first launched.
>>>>
>>>> But it could though couldn't it? Can't the slave guest just have full
>>>> access to it's own address space (probably very similar to the masters
>>>> address space) from machine init time? This seems more realistic than
>>>> setting up the hardware based on guest level information.
>>>
>>>
>>> Actually the address space for a slave is built at init time, the thing
>>> that
>>> is not
>>> completely configured is the memory region modeling the RAM. Such region
>>> is
>>> configured
>>> in terms of size, but there is no pointer to the actual memory. The
>>> pointer
>>> is mmap-ed later
>>> before the slave boots.
>>>
>> based on what information? Is the master guest controlling this? If so
>> what is the real-hardware analogue for this concept where the address
>> map of the slave can change (i.e. be configured) at runtime?
>
> I am not sure if it is the case since I haven't emulated this yet (and it
> has very low priority),
> but I might have a real case in my M3+A9 - M3 has 256MiB window that can be
> moved over the 1GiB system memory at runtime.
>

Right, the main thing for me there, is it works at runtime. The master
in Christians scheme would be able to remap it by configuring
registers. The same runtime reconfigurability should apply to the
slave memory mapping. Rather than having to declare the slave memory
map pre machine init, it should just be runtime configured by such a
device. Then there is no need for inter-qemu communication of
machine-init data. The two machines are inited independently, with the
communication channel only being used for runtime data. If there is
hardware support for it, remapping another processors address space is
a valid runtime operation for which we have support for at core
layers.

Regards,
Peter

>

>>>
>>>
> Regards,
> Marcin