From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sheng Yang Subject: Re: [PATCH 0/1] x2apic implementation for kvm Date: Mon, 25 May 2009 17:59:07 +0800 Message-ID: <200905251759.08421.sheng@linux.intel.com> References: <1242927475-6140-1-git-send-email-gleb@redhat.com> <200905251719.16009.sheng@linux.intel.com> <4A1A635A.1000000@redhat.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: Gleb Natapov , kvm@vger.kernel.org To: Avi Kivity Return-path: Received: from mga06.intel.com ([134.134.136.21]:14918 "EHLO orsmga101.jf.intel.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751649AbZEYJ5m (ORCPT ); Mon, 25 May 2009 05:57:42 -0400 In-Reply-To: <4A1A635A.1000000@redhat.com> Content-Disposition: inline Sender: kvm-owner@vger.kernel.org List-ID: On Monday 25 May 2009 17:22:34 Avi Kivity wrote: > 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) Need PV(at least part of). I don't think Hyper-V considered this, and not sure the community's aptitude. > - no need to read back ICR to look at the busy bit > - one ICR write instead of two Maybe the key issue. > - potential to support large guests once we add interrupt remapping Then it can be added before we have it. Compared to the workload, x2apic is not the problem, interrupt remapping/VT-d is. > - shared code with the Hyper-V paravirt interface So I think the key thing are ICR related(and seems no data available currently). Compare the benefit of ICR improve(can it improved in another way? Does Hyper-V interface has related things?), and the workload of x2apic virtualization as well as guest OS support, well, I don't know, but not optimistic. -- regards Yang, Sheng