From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 0/1] x2apic implementation for kvm Date: Mon, 25 May 2009 12:22:34 +0300 Message-ID: <4A1A635A.1000000@redhat.com> References: <1242927475-6140-1-git-send-email-gleb@redhat.com> <200905251448.04183.sheng@linux.intel.com> <4A1A5FD5.5090406@redhat.com> <200905251719.16009.sheng@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Gleb Natapov , kvm@vger.kernel.org To: Sheng Yang Return-path: Received: from mx2.redhat.com ([66.187.237.31]:33268 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752717AbZEYJWf (ORCPT ); Mon, 25 May 2009 05:22:35 -0400 In-Reply-To: <200905251719.16009.sheng@linux.intel.com> Sender: kvm-owner@vger.kernel.org List-ID: Sheng Yang wrote: > I think that means the PV interface for lapic. And yes, we can support it > follow MS's interface, but x2apic still seems another story as you noted... I > still don't think support x2apic here would bring us more benefits. > x2apic has the following benefit: - msr exits are faster than mmio (no page table walk, emulation) - no need to read back ICR to look at the busy bit - one ICR write instead of two - potential to support large guests once we add interrupt remapping - shared code with the Hyper-V paravirt interface -- error compiling committee.c: too many arguments to function