Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753724AbbG1FJM (ORCPT ); Tue, 28 Jul 2015 01:09:12 -0400 Received: from mga14.intel.com ([192.55.52.115]:46363 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750712AbbG1FJK convert rfc822-to-8bit (ORCPT ); Tue, 28 Jul 2015 01:09:10 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.15,560,1432623600"; d="scan'208";a="614206797" From: "Wu, Feng" To: Paolo Bonzini , Eric Auger , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" CC: "alex.williamson@redhat.com" , "joro@8bytes.org" , "Wu, Feng" Subject: RE: [v5 15/19] KVM: eventfd: add irq bypass consumer management Thread-Topic: [v5 15/19] KVM: eventfd: add irq bypass consumer management Thread-Index: AQHQvXJ9vWT9pDA87UCTHt2KBP8c6Z3wZ7JA Date: Tue, 28 Jul 2015 05:06:15 +0000 Message-ID: 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> <55A3C16B.4040502@redhat.com> In-Reply-To: <55A3C16B.4040502@redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2075 Lines: 48 > -----Original Message----- > From: Paolo Bonzini [mailto:pbonzini@redhat.com] > Sent: Monday, July 13, 2015 9:47 PM > To: Eric Auger; Wu, Feng; kvm@vger.kernel.org; linux-kernel@vger.kernel.org > Cc: alex.williamson@redhat.com; joro@8bytes.org > Subject: Re: [v5 15/19] KVM: eventfd: add irq bypass consumer management > > 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. I think dummy kvm_arch_* is okay for me. However, my point is that currently 'add_producer ' and 'del_producer ' are mandatory, other callbacks are optional. In patch "[RFC v2 5/6] KVM: introduce kvm_arch functions for IRQ bypass " and "[RFC v2 6/6] KVM: eventfd: add irq bypass consumer management ", it provides all the callbacks, which means we need to implement dummy arch specific functions no matter it is necessary. In that case, seems it is pointless to make some of the callbacks optional. Anyway, if you guys are fine with the dummy approach, I am good! :) Thanks, Feng > > Paolo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/