From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [v5 15/19] KVM: eventfd: add irq bypass consumer management Date: Mon, 13 Jul 2015 15:47:23 +0200 Message-ID: <55A3C16B.4040502@redhat.com> References: <1436780855-3617-1-git-send-email-feng.wu@intel.com> <1436780855-3617-16-git-send-email-feng.wu@intel.com> <55A3BA2D.9070707@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: alex.williamson@redhat.com, joro@8bytes.org To: Eric Auger , Feng Wu , kvm@vger.kernel.org, linux-kernel@vger.kernel.org Return-path: In-Reply-To: <55A3BA2D.9070707@linaro.org> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org 13/07/2015 15:16, Eric Auger wrote: >> > >> > + irqfd->consumer.token = (void *)irqfd->eventfd; >> > + kvm_arch_irq_consumer_init(&irqfd->consumer); > what if the architecture does not implement kvm_arch_irq_consumer_init? > > Also you are using here this single function kvm_arch_irq_consumer_init > to do some irq bypass manager settings + attaching your > irqfd->arch_update cb which does not really relate to IRQ bypass > manager. I think I preferred the approach where start/top/add/del were > exposed separately ([RFC v2 5/6] KVM: introduce kvm_arch functions for > IRQ bypass). > > Why not adding another kvm_arch_irq_routing_update then, not necessarily > linked to irq bypass manager. Yes, I also preferred the dummy kvm_arch_* functions to this approach with an init function. You'd have to add dummy init functions anyway for non-ARM, non-x86 architectures. Paolo