From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:38042) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEb2p-0004TH-N7 for qemu-devel@nongnu.org; Thu, 20 Sep 2012 03:19:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TEb2j-00089K-EI for qemu-devel@nongnu.org; Thu, 20 Sep 2012 03:19:31 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37446) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEb2j-00089G-5d for qemu-devel@nongnu.org; Thu, 20 Sep 2012 03:19:25 -0400 Date: Thu, 20 Sep 2012 10:19:13 +0300 From: Gleb Natapov Message-ID: <20120920071912.GX20907@redhat.com> References: <50587258.9090303@siemens.com> <20120919133720.GB22659@snow> <5059D26E.2050808@siemens.com> <5059DAC4.9020907@siemens.com> <505AC257.3080000@siemens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <505AC257.3080000@siemens.com> Subject: Re: [Qemu-devel] Will the ELI incorporated in theKVM? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Nadav Har'El , GaoYi , "qemu-devel@nongnu.org" , Michael D Day , Avi Kivity , Muli Ben-Yehuda , Nadav Amit , Abel Gordon On Thu, Sep 20, 2012 at 09:14:31AM +0200, Jan Kiszka wrote: > On 2012-09-20 08:58, Abel Gordon wrote: > > > > > > GaoYi wrote on 20/09/2012 08:42:51 AM: > > > >> The CPU isolation in Hitachi patches is just to improve the real > >> time performance of GUEST. The core of it, direct IRQ delivery, is > >> very similar to that of ELI. > >> For the ELI patches, > >> (1) Since EOI part of ELI is already supported by the Intel > >> Sandy Bridge CPUs and requires modifications on GUEST code, it > >> should not be included in the KVM. Only the ELI delivery part, which > >> plays a vital role in performance improvement, should be considered. > > > > Giving to the guest direct access to the EOI MSR (if x2APIC is available) > > is what we call "ELI completion". Note this mechanism is not so simple, > > there are some cases (which are not part of the critical path) where ELI > > must trap > > EOIs. For the APLOS paper evaluation we didn't have CPUs with x2APIC so we > > simulated the behavior changing the guest code. > > In any case, as you can see in the paper, the big part of the improvement > > comes from "ELI delivery". "ELI completion" improvement will be > > even smaller with the latest KVM EOI optimizations for the memory based > > LAPIC. > > > >> (2) It should be provided in the kvm-kmod or qemu-kvm ( not just > >> for some linux kernel as Hitachi patches do), to make this part > >> independent of linux kernel version. > > > > Exactly, ELI only modifies the kvm kernel module and qemu-kvm but we should > > also modify VFIO for newer kvm versions. > > Again: If you think the feature is non-invasive, send patches against > the kernel and QEMU. > And explain why it is better than what modern HW provides. -- Gleb.