public inbox for kvm-ppc@vger.kernel.org
 help / color / mirror / Atom feed
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.

  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