All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Fedin <p.fedin@samsung.com>
To: 'Peter Maydell' <peter.maydell@linaro.org>
Cc: 'Shlomo Pongratz' <shlomo.pongratz@huawei.com>,
	'Shlomo Pongratz' <shlomopongratz@gmail.com>,
	'QEMU Developers' <qemu-devel@nongnu.org>,
	'Eric Auger' <eric.auger@linaro.org>
Subject: Re: [Qemu-devel] [PATCH v12 5/5] hw/arm/virt: Add gic-version	option to virt machine
Date: Fri, 04 Sep 2015 17:18:57 +0300	[thread overview]
Message-ID: <01ec01d0e71c$a3b60520$eb220f60$@samsung.com> (raw)
In-Reply-To: <CAFEAcA-+_OnhpfWOwV3YN7WAgLO0PcStB1HvDr2kSe+GaGbfGw@mail.gmail.com>

 Hello!

> I think we need to leave enough space for all of GICC/GICV/GICH
> (that's 2 pages for GICC, 2 for GICV, 1 for GICH). They're optional
> in a GICv3, but we may want them for emulation later on and if we
> haven't left ourselves enough space we'll be a bit stuck.

 Do we really need this? Are we going to have a model with HYP mode, inside of which we could run another model? BTW, our GICv2 implementation also doesn't assume that it can have GICV/GICH.
 Additionally, according to GIC-500 arch manual, GICC_DIR with affinity routing enabled has an offset of 0x10000, and it's 17 pages instead of 2.
 Do we want to waste our precious address space?
 But, well, i have calculated that we would have 124 maximum CPUs instead of 126. So - your final word on this?

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia

  parent reply	other threads:[~2015-09-04 14:19 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-26 10:28 [Qemu-devel] [PATCH v12 0/5] vGICv3 support Pavel Fedin
2015-08-26 10:28 ` [Qemu-devel] [PATCH v12 1/5] hw/intc: Implement GIC-500 base class Pavel Fedin
2015-09-03 14:22   ` Peter Maydell
2015-08-26 10:28 ` [Qemu-devel] [PATCH v12 2/5] intc/gic: Extract some reusable vGIC code Pavel Fedin
2015-09-03 14:59   ` Peter Maydell
2015-09-04  6:54     ` Pavel Fedin
2015-09-04  8:47       ` Peter Maydell
2015-08-26 10:28 ` [Qemu-devel] [PATCH v12 3/5] arm_kvm: Do not assume particular GIC type in kvm_arch_irqchip_create() Pavel Fedin
2015-09-03 15:10   ` Peter Maydell
2015-08-26 10:28 ` [Qemu-devel] [PATCH v12 4/5] hw/intc: Initial implementation of vGICv3 Pavel Fedin
2015-08-26 10:28 ` [Qemu-devel] [PATCH v12 5/5] hw/arm/virt: Add gic-version option to virt machine Pavel Fedin
2015-09-03 17:08   ` Peter Maydell
2015-09-04  7:26     ` Pavel Fedin
2015-09-04  8:52       ` Peter Maydell
2015-09-04 15:06       ` Diana Craciun
2015-09-04 15:53         ` Pavel Fedin
2015-09-04 14:18     ` Pavel Fedin [this message]
2015-09-04 14:25       ` Peter Maydell
2015-09-04 14:53         ` Pavel Fedin
2015-09-08  8:18     ` Pavel Fedin

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='01ec01d0e71c$a3b60520$eb220f60$@samsung.com' \
    --to=p.fedin@samsung.com \
    --cc=eric.auger@linaro.org \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=shlomo.pongratz@huawei.com \
    --cc=shlomopongratz@gmail.com \
    /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.