All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anup Patel <anup@brainfault.org>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "patches@linaro.org" <patches@linaro.org>,
	qemu-devel@nongnu.org,
	"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>
Subject: Re: [Qemu-devel] [PATCH v4 2/2] ARM: Add 'virt' platform
Date: Mon, 5 Aug 2013 17:52:46 +0530	[thread overview]
Message-ID: <CAAhSdy3XvG2zKMXr2N=jC3HX8OQeY9LjvCpXCw3VA9UrxYuATw@mail.gmail.com> (raw)
In-Reply-To: <CAFEAcA9xE7CoiwXN09uNpU6c2c0hOrGQQkBJzZTLyUj26QR51w@mail.gmail.com>

On Mon, Aug 5, 2013 at 5:31 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
> On 5 August 2013 12:48, Anup Patel <anup@brainfault.org> 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 ?
What about Cortex-A7 and Cortex-A12  ?

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.

>
>> This will enable us to create 2 MB
>> entries in Stage2 TTBL for trapping which in-turn can help in performance
>> by reducing Stage2 TTBL walks.
>>
>> I am sure there won't be too many peripherals in mach-virt so, it would
>> even better if we can have base address of each peripheral to be at
>> 2 MB boundary.
>
> 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.

>
> thanks
> -- PMM

  reply	other threads:[~2013-08-05 12:23 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-05 11:18 [Qemu-devel] [PATCH v4 0/2] ARM: add 'virt' platform Peter Maydell
2013-08-05 11:18 ` [Qemu-devel] [PATCH v4 1/2] ARM: Allow boards to provide an fdt blob Peter Maydell
2013-08-05 11:18 ` [Qemu-devel] [PATCH v4 2/2] ARM: Add 'virt' platform Peter Maydell
2013-08-05 11:20   ` Peter Maydell
2013-08-05 11:48   ` Anup Patel
2013-08-05 12:01     ` Peter Maydell
2013-08-05 12:22       ` Anup Patel [this message]
2013-08-05 12:28         ` Peter Maydell
2013-08-05 12:37           ` Anup Patel
2013-08-05 12:43             ` Peter Maydell
2013-08-05 12:49 ` [Qemu-devel] Versioned machine types for ARM/non-x86 ? (Was Re: [PATCH v4 0/2] ARM: add 'virt' platform) Daniel P. Berrange
2013-08-05 13:02   ` Peter Maydell
2013-08-05 13:50     ` Daniel P. Berrange
2013-08-05 13:28   ` Anthony Liguori
2013-08-05 13:49     ` Daniel P. Berrange
2013-08-05 14:12       ` Anthony Liguori
2013-08-05 15:06         ` Gerd Hoffmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAAhSdy3XvG2zKMXr2N=jC3HX8OQeY9LjvCpXCw3VA9UrxYuATw@mail.gmail.com' \
    --to=anup@brainfault.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=patches@linaro.org \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.