qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v4 2/2] ARM: Add 'virt' platform


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH v4 2/2] ARM: Add 'virt' platform
Date: Mon, 5 Aug 2013 13:28:19 +0100

On 5 August 2013 13:22, Anup Patel <address@hidden> wrote:
> On Mon, Aug 5, 2013 at 5:31 PM, Peter Maydell <address@hidden> wrote:
>> On 5 August 2013 12:48, Anup Patel <address@hidden> wrote:
>>>> +static const MemMapEntry a15memmap[] = {
>>>> +    [VIRT_FLASH] = { 0, 0x100000 },
>>>
>>> IMHO, 1 MB of flash is small for possible future expansion. If mach-virt
>>> becomes popular then we can expect people running UBoot or UEFI or
>>> .... from this flash.
>>>
>>> I think having 16 MB of flash would be good because it is multiple of
>>> 2 MB hence we can also create section entries for it in Stage2 TTBL.
>>
>> Seems reasonable.
>>
>>>> +    [VIRT_CPUPERIPHS] = { 0x100000, 0x8000 },
>>>
>>> I would suggest to start peripheral space at 2 MB boundary and also
>>> have its total size in multiple of 2 MB.
>>
>> The total size here is fixed by the CPU hardware -- an A15's
>> private peripheral space is only 0x8000 in size.
>
> Does this mean, mach-virt address space is Cortex-A15 specific ?

The patch has support for an array of VirtBoardInfo structs,
each of which has its own memmap. The only entry at the
moment is for the A15.

> What about Cortex-A7 and Cortex-A12  ?

QEMU supports neither of these CPUs. The A7's the same as
the A15, though.

> If above is a mandatory constraint then we can have peripheral space divide
> into two parts:
> 1. Essential (or MPCore) peripherals: For now only GIC belongs here. Other
> things that fit here is Watchdog and Local timers but this are redundant for
> mach-virt. This space can be only 0x8000 in size as required by Cortex-A15.
> 2. General peripherals: All VirtIO devices would belong here. In addition,
> users can also add devices to this space using QEMU command line.

Er, this is what the patch already does. The "CPUPERIPHS"
bit is specifically for the CPU's private peripheral region.

You can't add an MMIO device on the QEMU command line, there's
no way to wire up the memory regions and IRQs.

>> Why does each individual peripheral have to be at a 2MB boundary?
>> I would expect the kernel to just have a single "nothing mapped"
>> here stage 2 table entry (or entries) covering the whole of the
>> mmio peripheral region regardless of how many devices happen
>> to be inside it.
>
> Yes, this seem a little over-kill but we can atleast have peripheral space to
> be 2MB aligned with total size in multiple of 2MB.

I really don't want to eat 2MB for each virtio-mmio transport
in a 32 bit address space, it seems hugely wasteful unless
there's a good reason to do it.

-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]