Re: [Xen-devel] [PATCH ARM v4 10/12] mini-os: get RAM base and size from the FDT

[Thomas Leonard <talex5@xxxxxxxxx>]

On 18 June 2014 18:38, Julien Grall <julien.grall@xxxxxxxxxx> wrote:
> Hi Thomas,
>
> On 06/18/2014 04:08 PM, Thomas Leonard wrote:
>> +        const char *device_type = fdt_getprop(device_tree, node, 
>> "device_type", NULL);
>> +        if (device_type && !strcmp(device_type, "memory"))
>> +        {
>> +            /* Note: we assume there's only a single region of memory.
>> +             * Since Xen is already translating our "physical"
>> +             * addresses to the real physical RAM, there's no
>> +             * reason for it to give us multiple blocks. */
>
> This comment looks wrong to me. Even tho, Xen is providing a stage-2
> translation to show you a virtual layout (your guest physical memory),
> the new layout in Xen upstream may contain multiple banks. The first
> bank will contain up to 3G of RAM.

Hi Julien,

At the Hackathon, we decided Mini-OS could always rely on Xen to
provide the memory in a single block:

"ARM guests are allowed to assume one bank of memory. We need to
document this in the ABI. ARM guests should assume the presence of an
FDT."

http://lists.xenproject.org/archives/html/mirageos-devel/2014-06/msg00004.html

A lot of the value of running on Xen is that we only have to support a
small number of configurations, because Xen hides the details of the
physical hardware. I assume the only reason for using the (very
flexible) FDT format to provide this information is that it's simpler
for full OSs which already use FDTs.

Is the ARM guest ABI documented somewhere?


>> index d2d5264..d31ef97 100644
>> --- a/extras/mini-os/mm.c
>> +++ b/extras/mini-os/mm.c
>> @@ -409,8 +409,8 @@ void init_mm(void)
>>       * now we can initialise the page allocator
>>       */
>>      printk("MM: Initialise page allocator for %lx(%lx)-%lx(%lx)\n",
>> -           (u_long)to_virt(PFN_PHYS(start_pfn)), PFN_PHYS(start_pfn),
>> -           (u_long)to_virt(PFN_PHYS(max_pfn)), PFN_PHYS(max_pfn));
>> +           (u_long)to_virt(PFN_PHYS(start_pfn)), 
>> (u_long)PFN_PHYS(start_pfn),
>> +           (u_long)to_virt(PFN_PHYS(max_pfn)), (u_long)PFN_PHYS(max_pfn));
>
> I don't see any modification of the type of max_pfn, start_pfn,
> PFN_PHYS. This change should not be part of this patch.




-- 
Dr Thomas Leonard        http://0install.net/
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel