From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sheng Yang Subject: Re: [PATCH 1/7] KVM: Add a route layer to convert MSI message to GSI Date: Sat, 10 Jan 2009 20:28:06 +0800 Message-ID: <20090110122806.GA27650@yukikaze> References: <1231411535-2461-1-git-send-email-sheng@linux.intel.com> <1231411535-2461-2-git-send-email-sheng@linux.intel.com> <496616E9.5040007@redhat.com> <200901091050.59817.sheng@linux.intel.com> <49679209.1030600@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sheng Yang , Marcelo Tosatti , kvm@vger.kernel.org To: Avi Kivity Return-path: Received: from rv-out-0506.google.com ([209.85.198.228]:51648 "EHLO rv-out-0506.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752152AbZAJM2K (ORCPT ); Sat, 10 Jan 2009 07:28:10 -0500 Received: by rv-out-0506.google.com with SMTP id k40so9374140rvb.1 for ; Sat, 10 Jan 2009 04:28:09 -0800 (PST) Content-Disposition: inline In-Reply-To: <49679209.1030600@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Fri, Jan 09, 2009 at 08:06:01PM +0200, Avi Kivity wrote: > Sheng Yang wrote: >> I just use it as #ifdef in userspace now, for no user other than >> MSI/MSI-X now. And if we keep maintaining it in kernel, we would return >> free size instead of maximum size.. >> > > We need to allow userspace to change pic/ioapic routing for the HPET. > > There are two styles of maintaining the table: > > 1. add/remove ioctls > > The advantage is that very little work needs to be done when something > changes, but the code size (and bug count) doubles. > > 2. replace everything ioctl > > Smaller code size, but slower if there are high frequency changes > > I don't think we'll see high frequency interrupt routing changes; we'll > probably have one on setup (for HPET), another when switching from ACPI > PIC mode to ACPI APIC mode, and one for every msi initialized. Hi, Avi After reconsidering, I must say I prefer add/remove ioctls. About the code size, I don't think it would increase much. I've rewritten the code twice, I think I know the difference is little. For the option 2 route table ioctl, we got a array from userspace, and would convert it to linked list and keep it in kernel. That's a kind of must(I don't think you would prefer use a array in kernel), and it's very direct. So, we have to insert/delete route entry for both. What's the real difference we do it one by one or do it all at once. I don't think it is much different on the code size. And it's indeed very clear and direct. Beside this, option 2 seems strange. Why should we handle this table in this way when it won't result in significant code reduce. Insert/delete entry it there, look up entry is also there, not many things changed. And it's not that direct as option 1, which also can be a source of bugs. How do you think? -- regards Yang, Sheng |Intel Opensource Technology Center