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: Mon, 12 Jan 2009 14:53:07 +0800 Message-ID: <200901121453.08583.sheng@linux.intel.com> References: <1231411535-2461-1-git-send-email-sheng@linux.intel.com> <20090110122806.GA27650@yukikaze> <4969BE0E.7070206@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , kvm@vger.kernel.org To: Avi Kivity Return-path: Received: from mga06.intel.com ([134.134.136.21]:59228 "EHLO orsmga101.jf.intel.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751253AbZALGxO (ORCPT ); Mon, 12 Jan 2009 01:53:14 -0500 In-Reply-To: <4969BE0E.7070206@redhat.com> Content-Disposition: inline Sender: kvm-owner@vger.kernel.org List-ID: On Sunday 11 January 2009 17:38:22 Avi Kivity wrote: > Sheng Yang wrote: > > 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. > > > :( sorry about that. > : > > 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. > > Actually, eventually we'd want an array indexed by gsi. Each element > would be a pointer to another array (one or two routing entries). > > Certainly we don't want to iterate a list which could hold several > hundred interrupts for a large guest. > > It's okay to start with a linked list, but eventually we'll want > something faster. Oh, I see. What I means here is allocate/deallocate would cause some memory fragments, but seems not that critical here. > > > 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? > > I'm not convinced. Please post your latest, and I will post a > counter-proposal. OK. -- regards Yang, Sheng