From: Gleb Natapov <gleb@redhat.com>
To: Christoffer Dall <cdall@cs.columbia.edu>
Cc: Scott Wood <scottwood@freescale.com>,
Alexander Graf <agraf@suse.de>,
kvm-ppc@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [RFC PATCH 1/6] kvm: add device control API
Date: Tue, 19 Feb 2013 12:45:30 +0000 [thread overview]
Message-ID: <20130219124529.GG3600@redhat.com> (raw)
In-Reply-To: <CAEDV+gKU604RN5uh0=xbFVPMYUfvqdqLbVc0nxJJykO2cCoivA@mail.gmail.com>
On Mon, Feb 18, 2013 at 09:50:44PM -0800, Christoffer Dall wrote:
> >> > +static int kvm_ioctl_create_device(struct kvm *kvm,
> >> > + struct kvm_create_device *cd)
> >> > +{
> >> > + struct kvm_device *dev = NULL;
> >> > + bool test = cd->flags & KVM_CREATE_DEVICE_TEST;
> >> > + int id;
> >> > + int r;
> >> > +
> >> > + mutex_lock(&kvm->lock);
> >> > +
> >> > + id = kvm->num_devices;
> >> > + if (id >= KVM_MAX_DEVICES && !test) {
> >> > + r = -ENOSPC;
> >> > + goto out;
> >> > + }
> >> > +
> >> > + switch (cd->type) {
> >> > + default:
> >> > + r = -ENODEV;
> >> > + goto out;
> >> > + }
> >>
> >> do we really believe that there will be any arch-generic recognition
> >> of types? shouldn't this be a call to an arch-specific function
> >> instead. Which makes me wonder whether the device type IDs should be
> >> arch specific as well...
> >
> >
> > I prefer to look at it from the other direction -- is there any reason why
> > this *should* be architecture specific? What will that make easier?
> >
>
> The fact that you don't have to create static inlines for the
> architectures that don't define the functions that get called or have
> to similar #ifdef tricks, and I also think it's easier to read the
> arch-specific bits of the code that way, instead of some arbitrary
> function that you have to trace through to figure out where it's
> called from.
>
> > By doing device recognition here we don't need a separate copy of this per
> > arch (including some #ifdef or modifying every arch at once -- including ARM
> > which I can't modify yet because it's not merged), and *if* we should end up
> > with an in-kernel-emulated device that gets used across multiple
> > architectures, it would be annoying to have to modify all relevant
> > architectures (and worse to deal with per-arch numberspaces).
>
> I would say that's exactly what you're going to need with your approach:
>
> switch (cd->type) {
> case KVM_ARM_VGIC_V2_0:
> kvm_arm_vgic_v2_0_create(...);
> }
>
>
> are you going to ifdef here in this function, or? I think it's cleaner
> to have the single arch-specific hooks and handle the cases there.
>
That is exactly what last patch is doing:
+#ifdef CONFIG_KVM_MPIC
+ case KVM_DEV_TYPE_FSL_MPIC_20:
+ case KVM_DEV_TYPE_FSL_MPIC_42: {
+ if (test) {
+ r = 0;
+ break;
+ }
+
+ r = kvm_create_mpic(kvm, cd->type, &dev);
+ break;
+ }
+#endif
> The use case of having a single device which is so central to the
> system that we emulate it inside the kernel and is shared across
> multiple archs is pretty far fetched to me.
>
There is (or should I say was) one such device: IOAPIC. It is shared
between ia64 and x86.
Unless we have device that is shared between all/some arches I am with
Christoffer on this one. If such device will appear we ca do:
kvm_ioctl_create_device()
{
switch (cd->type) {
case DEVICEA_SHARED_BY_ALL_ARCHS:
r = createa()
break;
case DEVICEB_SHARED_BY_ALL_ARCHS:
r = createb()
break;
default:
r = kvm_ioctl_arch_create_device();
}
}
--
Gleb.
next prev parent reply other threads:[~2013-02-19 12:45 UTC|newest]
Thread overview: 130+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-14 5:49 [RFC PATCH 0/6] kvm/ppc/mpic: in-kernel irqchip Scott Wood
2013-02-14 5:49 ` [RFC PATCH 1/6] kvm: add device control API Scott Wood
2013-02-18 12:21 ` Gleb Natapov
2013-02-18 23:01 ` Scott Wood
2013-02-19 0:43 ` Christoffer Dall
2013-02-19 12:24 ` Gleb Natapov
2013-02-19 15:51 ` Christoffer Dall
2013-02-19 21:16 ` Scott Wood
2013-02-20 13:09 ` Gleb Natapov
2013-02-20 21:28 ` Marcelo Tosatti
2013-02-20 22:44 ` Marcelo Tosatti
2013-02-20 23:53 ` Scott Wood
2013-02-21 0:14 ` Marcelo Tosatti
2013-02-21 1:28 ` Scott Wood
2013-02-21 6:39 ` Gleb Natapov
2013-02-21 23:03 ` Marcelo Tosatti
2013-02-22 2:00 ` Scott Wood
2013-02-23 15:04 ` Marcelo Tosatti
2013-02-26 0:27 ` Scott Wood
2013-02-21 2:05 ` Scott Wood
2013-02-21 8:22 ` Gleb Natapov
2013-02-22 2:17 ` Scott Wood
2013-02-24 15:46 ` Gleb Natapov
2013-02-25 15:23 ` Alexander Graf
2013-02-26 2:38 ` Scott Wood
2013-02-20 21:17 ` Marcelo Tosatti
2013-02-20 23:20 ` Scott Wood
2013-02-21 0:01 ` Marcelo Tosatti
2013-02-21 0:33 ` Scott Wood
2013-02-25 1:11 ` Paul Mackerras
2013-02-25 13:09 ` Gleb Natapov
2013-02-25 15:29 ` Alexander Graf
2013-02-19 0:44 ` Christoffer Dall
2013-02-19 0:53 ` Scott Wood
2013-02-19 5:50 ` Christoffer Dall
2013-02-19 12:45 ` Gleb Natapov [this message]
2013-02-19 20:16 ` Scott Wood
2013-02-20 2:16 ` Christoffer Dall
2013-02-24 13:12 ` Marc Zyngier
2013-03-06 0:59 ` Paul Mackerras
2013-03-06 1:20 ` Scott Wood
2013-03-06 2:48 ` Benjamin Herrenschmidt
2013-03-06 3:36 ` Scott Wood
2013-03-06 4:28 ` Benjamin Herrenschmidt
2013-03-06 10:18 ` Gleb Natapov
2013-02-14 5:49 ` [RFC PATCH 2/6] kvm/ppc: add a notifier chain for vcpu creation/destruction Scott Wood
2013-02-14 5:49 ` [RFC PATCH 3/6] kvm/ppc/mpic: import hw/openpic.c from QEMU Scott Wood
2013-02-14 5:49 ` [RFC PATCH 4/6] kvm/ppc/mpic: remove some obviously unneeded code Scott Wood
2013-02-14 5:49 ` [RFC PATCH 5/6] kvm/ppc/mpic: adapt to kernel style and environment Scott Wood
2013-02-14 5:49 ` [RFC PATCH 6/6] kvm/ppc/mpic: in-kernel MPIC emulation Scott Wood
2013-03-21 8:28 ` Alexander Graf
2013-03-21 14:43 ` Scott Wood
2013-03-21 14:52 ` Alexander Graf
2013-02-18 12:04 ` [RFC PATCH 0/6] kvm/ppc/mpic: in-kernel irqchip Gleb Natapov
2013-02-18 23:05 ` Scott Wood
2013-04-01 22:47 ` [RFC PATCH v2 0/6] device control and in-kernel MPIC Scott Wood
2013-04-01 22:47 ` [RFC PATCH v2 1/6] kvm: add device control API Scott Wood
2013-04-02 6:59 ` tiejun.chen
[not found] ` <1364923807.24520.2@snotra>
2013-04-03 1:28 ` tiejun.chen
[not found] ` <1364952853.8690.3@snotra>
2013-04-03 1:42 ` tiejun.chen
2013-04-03 1:02 ` Paul Mackerras
2013-04-03 1:19 ` Scott Wood
2013-04-03 2:17 ` Paul Mackerras
2013-04-03 13:22 ` Alexander Graf
2013-04-03 17:37 ` Scott Wood
2013-04-03 17:39 ` Alexander Graf
2013-04-04 9:58 ` Gleb Natapov
2013-04-03 21:03 ` Scott Wood
2013-04-01 22:47 ` [RFC PATCH v2 2/6] kvm/ppc/mpic: import hw/openpic.c from QEMU Scott Wood
2013-04-01 22:47 ` [RFC PATCH v2 3/6] kvm/ppc/mpic: remove some obviously unneeded code Scott Wood
2013-04-01 22:47 ` [RFC PATCH v2 4/6] kvm/ppc/mpic: adapt to kernel style and environment Scott Wood
2013-04-01 22:47 ` [RFC PATCH v2 5/6] kvm/ppc/mpic: in-kernel MPIC emulation Scott Wood
2013-04-01 22:47 ` [RFC PATCH v2 6/6] kvm/ppc/mpic: add KVM_CAP_IRQ_MPIC Scott Wood
2013-04-03 1:57 ` [RFC PATCH v3 0/6] device control and in-kernel MPIC Scott Wood
2013-04-03 1:57 ` [RFC PATCH v3 1/6] kvm: add device control API Scott Wood
2013-04-03 15:13 ` Alexander Graf
2013-04-04 10:41 ` Gleb Natapov
2013-04-04 23:47 ` Scott Wood
2013-04-08 10:34 ` Gleb Natapov
2013-04-05 1:02 ` Paul Mackerras
2013-04-08 10:37 ` Gleb Natapov
2013-04-08 5:33 ` Paul Mackerras
2013-04-09 0:50 ` Scott Wood
2013-04-03 1:57 ` [RFC PATCH v3 2/6] kvm/ppc/mpic: import hw/openpic.c from QEMU Scott Wood
2013-04-03 1:57 ` [RFC PATCH v3 3/6] kvm/ppc/mpic: remove some obviously unneeded code Scott Wood
2013-04-03 1:57 ` [RFC PATCH v3 4/6] kvm/ppc/mpic: adapt to kernel style and environment Scott Wood
2013-04-03 1:57 ` [RFC PATCH v3 5/6] kvm/ppc/mpic: in-kernel MPIC emulation Scott Wood
2013-04-03 15:55 ` Gleb Natapov
2013-04-03 20:58 ` Scott Wood
2013-04-04 5:59 ` Gleb Natapov
2013-04-04 23:33 ` Scott Wood
2013-04-08 10:39 ` Gleb Natapov
2013-04-03 16:19 ` Alexander Graf
2013-04-03 21:38 ` Scott Wood
2013-04-03 21:58 ` Alexander Graf
2013-04-03 22:07 ` Scott Wood
2013-04-03 22:12 ` Alexander Graf
2013-04-03 22:54 ` Scott Wood
2013-04-04 9:42 ` Alexander Graf
2013-04-03 23:23 ` Scott Wood
2013-04-08 6:30 ` Paul Mackerras
2013-04-09 0:49 ` Scott Wood
2013-04-03 1:57 ` [RFC PATCH v3 6/6] kvm/ppc/mpic: add KVM_CAP_IRQ_MPIC Scott Wood
2013-04-04 12:54 ` Alexander Graf
2013-04-04 18:41 ` Scott Wood
2013-04-04 22:30 ` Alexander Graf
2013-04-04 22:35 ` Scott Wood
2013-04-05 6:09 ` Alexander Graf
2013-04-05 17:11 ` Scott Wood
2013-04-13 0:08 ` [PATCH v4 0/6] device-control and in-kernel MPIC Scott Wood
2013-04-13 0:08 ` [PATCH v4 1/6] kvm: add device control API Scott Wood
2013-04-25 9:43 ` Gleb Natapov
2013-04-25 10:47 ` Alexander Graf
2013-04-25 12:07 ` Gleb Natapov
2013-04-25 13:45 ` Alexander Graf
2013-04-25 13:51 ` Gleb Natapov
2013-04-25 16:51 ` Scott Wood
2013-04-25 18:22 ` Gleb Natapov
2013-04-25 18:59 ` Scott Wood
2013-04-26 9:53 ` Gleb Natapov
2013-04-26 9:55 ` Alexander Graf
2013-04-26 9:57 ` Gleb Natapov
2013-04-13 0:08 ` [PATCH v4 2/6] kvm/ppc/mpic: import hw/openpic.c from QEMU Scott Wood
2013-04-13 0:08 ` [PATCH v4 3/6] kvm/ppc/mpic: remove some obviously unneeded code Scott Wood
2013-04-13 0:08 ` [PATCH v4 4/6] kvm/ppc/mpic: adapt to kernel style and environment Scott Wood
2013-04-13 0:08 ` [PATCH v4 5/6] kvm/ppc/mpic: in-kernel MPIC emulation Scott Wood
2013-04-13 0:08 ` [PATCH v4 6/6] kvm/ppc/mpic: add KVM_CAP_IRQ_MPIC Scott Wood
2013-04-15 5:23 ` Paul Mackerras
2013-04-15 17:52 ` Scott Wood
2013-04-16 3:59 ` Paul Mackerras
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=20130219124529.GG3600@redhat.com \
--to=gleb@redhat.com \
--cc=agraf@suse.de \
--cc=cdall@cs.columbia.edu \
--cc=kvm-ppc@vger.kernel.org \
--cc=kvm@vger.kernel.org \
--cc=scottwood@freescale.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