From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 1/7] KVM: Add a route layer to convert MSI message to GSI Date: Fri, 09 Jan 2009 20:06:01 +0200 Message-ID: <49679209.1030600@redhat.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , kvm@vger.kernel.org To: Sheng Yang Return-path: Received: from mx2.redhat.com ([66.187.237.31]:48132 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753453AbZAISFp (ORCPT ); Fri, 9 Jan 2009 13:05:45 -0500 In-Reply-To: <200901091050.59817.sheng@linux.intel.com> Sender: kvm-owner@vger.kernel.org List-ID: Sheng Yang wrote: >>> +struct kvm_gsi_route_entry_guest { >>> >> what does _guest mean here? almost all kvm stuff is _guest related. >> > > Because I can't think of a good name... kvm_gsi_route_entry_guest? > kvm_gsi_kernel_route_entry? What's your favorite? :) > > kvm_gsi_route_entry? >> >> Since we replace the entire table every time, how do ioapic/pic gsis work? >> Missed this question... >> Why not throw everything and set the new table? >> > > Userspace to maintain a big route table? Just for MSI/MSI-X it's easy, but for > others, a global one is needed, and need follow up more maintain functions. > For kernel, a little more effect can archive this, like this. So I do it in > this way. > Sorry, I don't understand the reply. >> I didn't see where you respond the new KVM_CAP. It looks like a good >> place to return the maximum size of the table. >> > > 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. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.