From: Peter Maydell <peter.maydell@linaro.org>
To: Pavel Fedin <p.fedin@samsung.com>
Cc: Diana Craciun <diana.craciun@freescale.com>,
Shlomo Pongratz <shlomo.pongratz@huawei.com>,
Shlomo Pongratz <shlomopongratz@gmail.com>,
QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [RFC PATCH v3 1/5] hw/intc: Implement ITS base class
Date: Fri, 27 Nov 2015 15:35:47 +0000 [thread overview]
Message-ID: <CAFEAcA9O65+coY1gS3pmWMn-p1MSwQNM_vVx7ZBRoFFFSAf03w@mail.gmail.com> (raw)
In-Reply-To: <48b59a60537a0dc5aac45b9015330eb641949ea5.1448359515.git.p.fedin@samsung.com>
On 24 November 2015 at 10:13, Pavel Fedin <p.fedin@samsung.com> wrote:
> This is the basic skeleton for both KVM and software-emulated ITS.
> Since we already prepare status structure, we also introduce complete
> VMState description. But, because we currently have no migratable
> implementations, we also set unmigratable flag.
>
> Signed-off-by: Pavel Fedin <p.fedin@samsung.com>
This mostly looks good, I just have a few minor points:
> +static uint64_t gicv3_its_trans_read(void *opaque, hwaddr offset, unsigned size)
> +{
> + qemu_log_mask(LOG_GUEST_ERROR, "ITS read at offset 0x%jX\n", offset);
> + return ~0ULL;
I don't think %j is the right format string character here or below:
(we don't use it anywhere else in QEMU and the docs say it is
for uintmax_t/intmax_t types).
> +}
> +static const MemoryRegionOps gicv3_its_trans_ops = {
> + .read = gicv3_its_trans_read,
> + .write_with_attrs = gicv3_its_trans_write,
Please make both read and write accessor be the _with_attrs form.
I know the read accessor doesn't need the attributes, but I think
it's neater to have them both the same within a given memory region.
> + .impl = {
> + .min_access_size = 4,
> + .max_access_size = 4,
The spec says that 16-bit access to bits [15:0] of GITS_TRANSLATER
must be supported.
> + },
> + .endianness = DEVICE_NATIVE_ENDIAN,
> +};
> +
> +void gicv3_its_init_mmio(GICv3ITSState *s, const MemoryRegionOps *ops)
> +{
> + SysBusDevice *sbd = SYS_BUS_DEVICE(s);
> +
> + memory_region_init_io(&s->iomem_its_cntrl, OBJECT(s), ops, s,
> + "control", ITS_CONTROL_SIZE);
> + memory_region_init_io(&s->iomem_its, OBJECT(s), &gicv3_its_trans_ops, s,
> + "translation", ITS_TRANS_SIZE);
> +
> + /* Our two regions are always adjacent, therefore we now combine them
> + * into a single one in order to make our users' life easier.
> + */
> + memory_region_init(&s->iomem_main, OBJECT(s), "gicv3_its", ITS_SIZE);
> + memory_region_add_subregion(&s->iomem_main, 0, &s->iomem_its_cntrl);
> + memory_region_add_subregion(&s->iomem_main, ITS_CONTROL_SIZE,
> + &s->iomem_its);
> + sysbus_init_mmio(sbd, &s->iomem_main);
So we have two memory subregions:
* the control register page, whose ops are passed in by the subclass
* the translation register page, whose only register is implemented
here by looking up the subclass and calling its send_msi method
Does that complexity gain us anything later? There doesn't really
seem to be anything much actually in common here, which would
suggest just having the subclasses create their own mmio region(s)
(which could then just directly implement the right behaviour for
GITS_TRANSLATER). Or does the emulated ITS have extra stuff that
makes this worthwhile?
> --- a/target-arm/kvm_arm.h
> +++ b/target-arm/kvm_arm.h
> @@ -215,4 +215,14 @@ static inline const char *gic_class_name(void)
> */
> const char *gicv3_class_name(void);
>
> +/**
> + * its_class_name
> + *
> + * Return name of ITS class to use depending on whether KVM acceleration is
> + * in use, or NULL if the chosen implementation is not available.
> + *
> + * Returns: class name to use or NULL
> + */
> +const char *its_class_name(void);
> +
> #endif
> diff --git a/target-arm/machine.c b/target-arm/machine.c
> index 36a0d15..6c59c53 100644
> --- a/target-arm/machine.c
> +++ b/target-arm/machine.c
> @@ -346,3 +346,19 @@ const char *gicv3_class_name(void)
>
> exit(1);
> }
> +
> +const char *its_class_name(void)
> +{
> + if (kvm_irqchip_in_kernel()) {
> +#ifdef TARGET_AARCH64
> + /* KVM implementation requires this capability */
> + if (kvm_direct_msi_enabled()) {
> + return "arm-its-kvm";
> + }
> +#endif
Why is this in an #ifdef? In theory we could support
the GICv3 in a 32-bit system. If it isn't supported
then I'd expect kvm_direct_msi_enabled() to return false
on a non-AArch64 system anyway.
> + return NULL;
> + } else {
> + /* Software emulation is not implemented yet */
> + return NULL;
> + }
> +}
This doesn't seem like it should be in machine.c, which is
purely related to code for migration. I would just make it
be an inline implementation in kvm-arm.h, like gic_class_name().
(I know gicv3_class_name is in machine.c, but I must have missed
that it was in an odd file when that patch went through review.
Sorry.)
thanks
-- PMM
next prev parent reply other threads:[~2015-11-27 15:36 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-24 10:13 [Qemu-devel] [RFC PATCH v3 0/5] vITS support Pavel Fedin
2015-11-24 10:13 ` [Qemu-devel] [RFC PATCH v3 1/5] hw/intc: Implement ITS base class Pavel Fedin
2015-11-27 15:35 ` Peter Maydell [this message]
2015-11-30 7:09 ` Pavel Fedin
2015-11-29 8:10 ` Shannon Zhao
2015-11-24 10:13 ` [Qemu-devel] [RFC PATCH v3 2/5] kernel: Add vGICv3 ITS definitions Pavel Fedin
2015-11-24 10:13 ` [Qemu-devel] [RFC PATCH v3 3/5] kvm_arm: Pass requester ID to MSI routing functions Pavel Fedin
2015-11-27 15:45 ` Peter Maydell
2015-11-30 6:41 ` Pavel Fedin
2015-11-24 10:13 ` [Qemu-devel] [RFC PATCH v3 4/5] kvm_arm: Implement support for ITS emulation by KVM Pavel Fedin
2015-11-27 15:47 ` Peter Maydell
2015-11-24 10:13 ` [Qemu-devel] [RFC PATCH v3 5/5] arm/virt: Add ITS to the virt board Pavel Fedin
2015-11-27 16:18 ` Peter Maydell
2015-11-28 3:55 ` Shannon Zhao
2016-06-28 6:41 ` [Qemu-devel] [RFC PATCH v3 0/5] vITS support Auger Eric
2016-06-28 8:25 ` Christoffer Dall
2016-06-29 6:45 ` Auger Eric
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=CAFEAcA9O65+coY1gS3pmWMn-p1MSwQNM_vVx7ZBRoFFFSAf03w@mail.gmail.com \
--to=peter.maydell@linaro.org \
--cc=diana.craciun@freescale.com \
--cc=p.fedin@samsung.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).