From: Pavel Fedin <p.fedin@samsung.com>
To: 'Eric Auger' <eric.auger@linaro.org>,
'Ashok Kumar' <ashoks@broadcom.com>,
qemu-devel@nongnu.org
Cc: 'Shlomo Pongratz' <shlomo.pongratz@huawei.com>
Subject: Re: [Qemu-devel] [RFC PATCH] hw/arm/virt: Added preliminary GICv3 support for kvm mode
Date: Thu, 21 May 2015 09:47:02 +0300 [thread overview]
Message-ID: <007101d09391$f20306d0$d6091470$@samsung.com> (raw)
In-Reply-To: <555B31A4.9050708@linaro.org>
Hello! Sorry, missed this message, catching up...
> After a closer look, kvm_arch_irqchip_create is called here with test
> mode = true. With that option, at kernel level, we only check the kvm
> device registered its ops and do not go further (see
> kvm_ioctl_create_device in kvm_main.c): typically the gic kvm_device is
> not created at that stage.
Ah, sorry, yes. I missed KVM_CREATE_DEVICE_TEST flag.
> So if my understanding is correct, that piece
> of code only should & does check either GICv2 or GICV3 was seen in the
> host dt and accordingly registered. I think Ashok
> kvm_arch_irqchip_create code is good here.
IMHO not really because from the beginning we want only a particular GIC type instead of
just something. And there can be a situation where we want e.g. GICv3 in our virtual
machine, but only GICv2 is supported by the KVM (because of hardware). Or vice versa, we
could ask for GICv2, but KVM could do only GICv3 (not all GICv3's have backwards
compatibility option).
Ashok's code would become confused in this case. It will probe for anything and return
OK, while the kernel actually cannot do what we really want.
And one more glitch. In case if we want GICv3, we should not return just false, because
in this case qemu falls back to KVM_CREATE_IRQCHIP ioctl, which does not have test mode,
and will actually instantiate GICv2. I believe this can cause problems.
To be more clear, here is a snip from my code. I can post the whole thing as RFC patches,
but they are not quite ready yet.
--- cut ---
int kvm_arch_irqchip_create(KVMState *s, int type)
{
int ret;
/* If we can create the VGIC using the newer device control API, we
* let the device do this when it initializes itself, otherwise we
* fall back to the old API */
ret = kvm_create_device(s, type, true);
if (ret == 0) {
return 1;
}
/* Fallback will create VGIC v2 */
if (type != KVM_DEV_TYPE_ARM_VGIC_V2) {
return ret;
}
return 0;
}
--- cut ---
'type' here comes from MachineState (see my last virt-v3 patch):
--- cut ---
static int kvm_irqchip_create(MachineState *machine, KVMState *s)
{
int ret;
if (!machine_kernel_irqchip_allowed(machine) ||
(!kvm_check_extension(s, KVM_CAP_IRQCHIP) &&
(kvm_vm_enable_cap(s, KVM_CAP_S390_IRQCHIP, 0) < 0))) {
return 0;
}
/* First probe and see if there's a arch-specific hook to create the
* in-kernel irqchip for us */
ret = kvm_arch_irqchip_create(s, machine->kernel_irqchip_type);
if (ret < 0) {
return ret;
} else if (ret == 0) {
ret = kvm_vm_ioctl(s, KVM_CREATE_IRQCHIP);
if (ret < 0) {
fprintf(stderr, "Create kernel irqchip failed\n");
return ret;
}
}
--- cut ---
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
next prev parent reply other threads:[~2015-05-21 6:47 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-14 17:27 [Qemu-devel] [RFC PATCH] hw/arm/virt: Added preliminary GICv3 support for kvm mode Ashok Kumar
2015-05-15 6:42 ` Pavel Fedin
2015-05-19 12:50 ` Eric Auger
2015-05-21 6:47 ` Pavel Fedin [this message]
2015-05-21 8:59 ` Eric Auger
2015-05-21 14:10 ` Pavel Fedin
2015-05-21 14:24 ` Eric Auger
2015-05-19 16:45 ` Eric Auger
2015-05-18 15:44 ` Eric Auger
2015-05-19 12:52 ` Eric Auger
-- strict thread matches above, loose matches on Subject: below --
2015-05-14 20:13 Ashok Kumar
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='007101d09391$f20306d0$d6091470$@samsung.com' \
--to=p.fedin@samsung.com \
--cc=ashoks@broadcom.com \
--cc=eric.auger@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=shlomo.pongratz@huawei.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).