From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [RFC] Moving the kvm ioapic, pic, and pit back to userspace Date: Mon, 07 Jun 2010 21:46:59 +0300 Message-ID: <4C0D3EA3.1010205@redhat.com> References: <4C0D0FB7.80709@redhat.com> <4C0D1EFA.70104@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: KVM list , qemu-devel To: "David S. Ahern" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:15006 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751343Ab0FGSr1 (ORCPT ); Mon, 7 Jun 2010 14:47:27 -0400 In-Reply-To: <4C0D1EFA.70104@cisco.com> Sender: kvm-owner@vger.kernel.org List-ID: On 06/07/2010 07:31 PM, David S. Ahern wrote: > > On 06/07/10 09:26, Avi Kivity wrote: > > >> The original motivation for moving the PIC and IOAPIC into the kernel >> was performance, especially for assigned devices. Both devices are high >> interaction since they deal with interrupts; practically after every >> interrupt there is either a PIC ioport write, or an APIC bus message, >> both signalling an EOI operation. Moving the PIT into the kernel >> allowed us to catch up with missed timer interrupt injections, and >> speeded up guests which read the PIT counters (e.g. tickless guests). >> >> However, modern guests running on modern qemu use MSI extensively; both >> virtio and assigned devices now have MSI support; and the planned VFIO >> only supports kernel delivery via MSI anyway; line based interrupts will >> need to be mediated by userspace. >> > The "modern" guest comment is a bit concerning. 2.4 kernels (e.g., > RHEL3) use the PIT for timekeeping and will still be around for a while. > RHEL4 and RHEL5 will be around for a long time to come. Not sure how > those fit within the "modern" label, though I see my RHEL4 guest is > using the pit as a timesource. > First of all, the existing code will remain for a long while (several years). We still have to support existing userspace. But, that's not a satisfactory answer. I don't want users to choose which device model to use according to their guest. As far as I'm concerned all guests are triple-boot with the guest rebooting to a different OS every half hour. So it's important to know how often your RHEL3/4 guest queries the PIT (not just receives interrupts, actually reads the counter) under a realistic load. If you have such a number (in reads/sec) that would be a good input to this discussion. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.