From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 0/1] IRQ Routing Date: Wed, 14 Jan 2009 16:31:29 +0200 Message-ID: <496DF741.9060707@redhat.com> References: <1231876950-10092-1-git-send-email-avi@redhat.com> <200901141639.29844.sheng@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: Xiantao Zhang , Marcelo Tosatti , kvm@vger.kernel.org To: Sheng Yang Return-path: Received: from mx2.redhat.com ([66.187.237.31]:46555 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753983AbZANObe (ORCPT ); Wed, 14 Jan 2009 09:31:34 -0500 In-Reply-To: <200901141639.29844.sheng@linux.intel.com> Sender: kvm-owner@vger.kernel.org List-ID: Sheng Yang wrote: > On Wednesday 14 January 2009 04:02:29 Avi Kivity wrote: > >> Following is my alternative to irq routing. The differences compared to >> Sheng's version are: >> >> - A single ioctl to replace the entire routing table, instead of add/remove >> ioctls for individual routing entries. Routing changes are rare, and >> we need to track the entire table in userspace anyway (for save/restore, >> and for user irqchip). As a side effect changes are atomic. >> - Interrupt numbers are allocated by userspace, instead of the kernel >> - I implemented irqchip routings rather then MSIs, it should be easy to >> add MSIs later on. >> >> Please review and comment. >> > > Look nice to me now... Save/restore is a good reason to maintain a table in > userspace. > > And looking forward to userspace patch. Put a table in kvm_context? > Sent out. I indeed placed a table in kvm_context, with add/del route APIs. -- error compiling committee.c: too many arguments to function