All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cornelia Huck <cornelia.huck@de.ibm.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: linux-s390 <linux-s390@vger.kernel.org>,
	qemu-devel <qemu-devel@nongnu.org>, KVM <kvm@vger.kernel.org>
Subject: Re: [RFC PATCH 1/3] KVM: s390: Move out initialization code.
Date: Thu, 21 Feb 2013 15:56:35 +0100	[thread overview]
Message-ID: <20130221155635.33de37b6@gondolin> (raw)
In-Reply-To: <20130221141834.GB24738@redhat.com>

On Thu, 21 Feb 2013 16:18:34 +0200
"Michael S. Tsirkin" <mst@redhat.com> wrote:

> On Thu, Feb 21, 2013 at 03:07:32PM +0100, Cornelia Huck wrote:
> > On Thu, 21 Feb 2013 15:43:55 +0200
> > "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > 
> > > On Thu, Feb 21, 2013 at 02:12:58PM +0100, Cornelia Huck wrote:
> > > > kvm-s390's module initialization code needs to live in a separate
> > > > module (kvm-s390.ko) if we want to include eventfd (which has its
> > > > own module init func).
> > > > 
> > > > Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
> > > 
> > > I don't get this explanation.
> > > What's the problem this solves?
> > > Could you clarify please?
> > 
> > On s390, we currently build a single 'kvm' module, with a module_init
> > function. eventfd has its own module_init function, and we can't have
> > two of them in the same module. I just moved our specific module
> > initialization into a new 'kvm_s390' module.
> 
> 
> You mean this?
> 
> virt/kvm/eventfd.c:static int __init irqfd_module_init(void)
> virt/kvm/eventfd.c:module_init(irqfd_module_init);
> 
> I see. Won't it be easier to just call irqfd_module_init
> from kvm_init?
> 
It does make it clearer what happens, and eliminates the need for a new
module on s390. I'll do that in the next round:

diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index d7965fb..55a6de1 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -423,6 +423,19 @@ void kvm_vcpu_uninit(struct kvm_vcpu *vcpu);
 int __must_check vcpu_load(struct kvm_vcpu *vcpu);
 void vcpu_put(struct kvm_vcpu *vcpu);
 
+#ifdef __KVM_HAVE_IOAPIC
+int kvm_irqfd_init(void);
+void kvm_irqfd_exit(void);
+#else
+static inline int kvm_irqfd_init(void)
+{
+	return 0;
+}
+
+static inline void kvm_irqfd_exit(void)
+{
+}
+#endif
 int kvm_init(void *opaque, unsigned vcpu_size, unsigned vcpu_align,
 		  struct module *module);
 void kvm_exit(void);
diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
index 63fe454..c631c4b 100644
--- a/virt/kvm/eventfd.c
+++ b/virt/kvm/eventfd.c
@@ -544,7 +544,7 @@ void kvm_irq_routing_update(struct kvm *kvm,
  * aggregated from all vm* instances. We need our own isolated single-thread
  * queue to prevent deadlock against flushing the normal work-queue.
  */
-static int __init irqfd_module_init(void)
+int kvm_irqfd_init(void)
 {
 	irqfd_cleanup_wq = create_singlethread_workqueue("kvm-irqfd-cleanup");
 	if (!irqfd_cleanup_wq)
@@ -553,13 +553,10 @@ static int __init irqfd_module_init(void)
 	return 0;
 }
 
-static void __exit irqfd_module_exit(void)
+void kvm_irqfd_exit(void)
 {
 	destroy_workqueue(irqfd_cleanup_wq);
 }
-
-module_init(irqfd_module_init);
-module_exit(irqfd_module_exit);
 #endif
 
 /*
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index adc68fe..7c188a3 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -2920,6 +2920,9 @@ int kvm_init(void *opaque, unsigned vcpu_size, unsigned vcpu_align,
 	int r;
 	int cpu;
 
+	r = kvm_irqfd_init();
+	if (r)
+		goto out_irqfd;
 	r = kvm_arch_init(opaque);
 	if (r)
 		goto out_fail;
@@ -3000,6 +3003,8 @@ out_free_0a:
 out_free_0:
 	kvm_arch_exit();
 out_fail:
+	kvm_irqfd_exit();
+out_irqfd:
 	return r;
 }
 EXPORT_SYMBOL_GPL(kvm_init);
@@ -3016,6 +3021,7 @@ void kvm_exit(void)
 	on_each_cpu(hardware_disable_nolock, NULL, 1);
 	kvm_arch_hardware_unsetup();
 	kvm_arch_exit();
+	kvm_irqfd_exit();
 	free_cpumask_var(cpus_hardware_enabled);
 }
 EXPORT_SYMBOL_GPL(kvm_exit);

  reply	other threads:[~2013-02-21 14:56 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-21 13:12 [RFC PATCH 0/3] kvm: Make ioeventfd usable on s390 Cornelia Huck
2013-02-21 13:12 ` [RFC PATCH 1/3] KVM: s390: Move out initialization code Cornelia Huck
2013-02-21 13:43   ` Michael S. Tsirkin
2013-02-21 14:07     ` Cornelia Huck
2013-02-21 14:18       ` Michael S. Tsirkin
2013-02-21 14:56         ` Cornelia Huck [this message]
2013-02-21 13:12 ` [RFC PATCH 2/3] KVM: Generalize ioeventfds Cornelia Huck
2013-02-21 13:13 ` [RFC PATCH 3/3] KVM: s390: Hook up ioeventfds Cornelia Huck
2013-02-21 14:39   ` Michael S. Tsirkin
2013-02-21 15:21     ` Cornelia Huck
2013-02-21 16:34       ` Michael S. Tsirkin
2013-02-21 18:14         ` Cornelia Huck
2013-02-21 20:42           ` Michael S. Tsirkin
2013-02-22  7:22             ` Cornelia Huck
2013-02-24  9:37               ` Michael S. Tsirkin

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=20130221155635.33de37b6@gondolin \
    --to=cornelia.huck@de.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /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.