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 14:48:03 +0800 Message-ID: <200905251448.04183.sheng@linux.intel.com> References: <1242927475-6140-1-git-send-email-gleb@redhat.com> <200905251430.06165.sheng@linux.intel.com> <20090525063811.GC3948@redhat.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org To: Gleb Natapov Return-path: Received: from mga06.intel.com ([134.134.136.21]:12571 "EHLO orsmga101.jf.intel.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750742AbZEYGqi (ORCPT ); Mon, 25 May 2009 02:46:38 -0400 In-Reply-To: <20090525063811.GC3948@redhat.com> Content-Disposition: inline Sender: kvm-owner@vger.kernel.org List-ID: On Monday 25 May 2009 14:38:11 Gleb Natapov wrote: > On Mon, May 25, 2009 at 02:30:05PM +0800, Sheng Yang wrote: > > On Monday 25 May 2009 14:13:23 Gleb Natapov wrote: > > > On Mon, May 25, 2009 at 02:08:26PM +0800, Sheng Yang wrote: > > > > On Friday 22 May 2009 01:37:53 Gleb Natapov wrote: > > > > > This is implementation of x2apic for KVM that I wrote a while ago. > > > > > Unfortunately there is no guest that can take advantage of it since > > > > > Linux doesn't (yet?) use x2apic if interrupt remapping is not > > > > > enabled and I don't feel like implement interrupt remapping device > > > > > :) > > > > > > > > > > Re-based to latest kvm tree for your viewing pleasure and feedback. > > > > > > > > Yeah... x2apic is for interrupt remapping, and interrupt remapping is > > > > for VT-d engine. So if we don't want to virtualize VT-d engine and > > > > interrupt remapping, x2apic is useless for the guest... And VT-d > > > > engine(and related things) virtualization is far from our scope > > > > now... > > > > > > Can you explain why "x2apic is for interrupt remapping"? I can > > > understand why interrupt remapping is needed to use x2apic in certain > > > circumstances (apic ids > 256). x2apic has better virtualizable > > > interface and that is why we want to emulate it. Can you name one > > > technical reason why it can't be done in a context of KVM? > > > > As you know, x2apic is for apic id > 256. So, at least on the real > > machine, if there is no interrupt remapping, x2apic almost can't take > > much advantage, because IOAPIC and MSI/MSI-X delivery still using 8bit > > apic id, so any external interrupt can't benefit from it(though IPI can > > benefit some, and maybe some gain from MSR rather than MMIO). And this is > > the main purpose for x2apic, that's why Linux kernel limited x2apic using > > with interrupt remapping. > > > > I am not sure the things looks like in the context of KVM. I think mostly > > even you virtualize it, it can't replace lapic, for guest won't use it(I > > am not sure about the Windows). Can you explain more detail? > > KVM will expose x2apic, but will use apic ids < 256. Linux has to be > changed to use x2apic if it runs as a guest. Windows, when running as a > guest, partially paravirtualize lapic by using MSRs to access frequently > used registers. The MSR interface Windows uses is very similar to x2apic > by the way and KVM will support it too. > OK, you are totally talking about PV. For PV, I think let host kernel accept the modification is more important here. (And for PV, using hypercall seems more directly). -- regards Yang, Sheng