From mboxrd@z Thu Jan 1 00:00:00 1970 From: Cyrill Gorcunov Subject: Re: [PATCH 1/2] kvm tools: Fix IRQ assignments Date: Fri, 06 May 2011 12:08:08 +0400 Message-ID: <4DC3AC68.10208@gmail.com> References: <1304666795-15251-1-git-send-email-levinsasha928@gmail.com> <1304667363.10534.5.camel@lappy> <1304668876.10534.9.camel@lappy> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Sasha Levin , mingo@elte.hu, asias.hejun@gmail.com, prasadjoshi124@gmail.com, kvm@vger.kernel.org To: Pekka Enberg Return-path: Received: from mail-ew0-f46.google.com ([209.85.215.46]:61965 "EHLO mail-ew0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754454Ab1EFIIN (ORCPT ); Fri, 6 May 2011 04:08:13 -0400 Received: by ewy4 with SMTP id 4so892667ewy.19 for ; Fri, 06 May 2011 01:08:12 -0700 (PDT) In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On 05/06/2011 12:04 PM, Pekka Enberg wrote: > On Fri, May 6, 2011 at 11:01 AM, Sasha Levin wrote: >> On Fri, 2011-05-06 at 10:43 +0300, Pekka Enberg wrote: >>> On Fri, May 6, 2011 at 10:36 AM, Sasha Levin wrote: >>>> afaik, we need to have same IRQ pins for devices which may have >>>> different IRQ lines (All virtio-blk share same IRQ pin but different >>>> line, I assume it'll be same with different virtio devices). >>>> >>>> So mptable has to manage association between device type and the >>>> corresponding IRQ pin/line assignment, So dynamic assignment will be >>>> more of a call with device type and return IRQ pin + line - which makes >>>> it more complex than just allocating next free IRQ line. >>> >>> Well then make kvm__request_irq() return a pointer to struct irq and >>> have a hard-coded array of IRQ pin + line pairs in irq.c, for example. >>> That'll reduce complexity in the virtio drivers and it'll serve as a >>> starting point for proper IRQ allocator. >> >> The big problem with dynamic allocations is having mptable register IRQ >> sources properly, So I went ahead and deleted IRQ source definitions >> from mptable.c and noticed that everything still works. >> >> I've spoke with Cyrill and neither him or myself were too sure if it's >> ok to do that now and if so, would it still be correct once SMP gets >> added. >> >> So here is my question: Would it be ok to drop IRQ source definitions >> from mptable? > > Now why do we need to do that? Shouldn't we pass the "device tree" to > mptable.c and build the IRQ mappings based on that? Isn't that exactly > what we do right now with the hard-coded enums? > > Pekka Yes, that is what we do, and it seems to be the "right" way how sane bios should behave, same time (i might be wrong since I didn't checked this part of kernel sources) the kernel might scan memory for pci configs and read pis/irq directly from there, I think this way kernel workaround broken bioses but now sure if we should rely on this feature. -- Thanks, Cyrill