From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yang Zhang Subject: Re: Enable more than 255 VCPU support without irq remapping function in the guest Date: Tue, 3 May 2016 09:52:53 +0800 Message-ID: <57280475.2080506@gmail.com> References: <571F93CA.40200@intel.com> <571F9487.5090009@siemens.com> <20160426164939.GA18900@potion> <57203B9D.6020402@gmail.com> <57204D28.4070706@siemens.com> <572088D0.7040805@gmail.com> <57208A54.40502@siemens.com> <57216341.80006@gmail.com> <5721B394.9050008@siemens.com> <20160428153251.GA17368@potion> <5722C247.6040004@gmail.com> <5722EA47.80205@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: "Lan, Tianyu" , pbonzini@redhat.com, kvm@vger.kernel.org, tglx@linutronix.de, gleb@redhat.com, mst@redhat.com, x86@kernel.org, Peter Xu , Igor Mammedov To: Jan Kiszka , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= Return-path: Received: from mail-oi0-f48.google.com ([209.85.218.48]:33618 "EHLO mail-oi0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932462AbcECBxE (ORCPT ); Mon, 2 May 2016 21:53:04 -0400 Received: by mail-oi0-f48.google.com with SMTP id v145so7978666oie.0 for ; Mon, 02 May 2016 18:53:03 -0700 (PDT) In-Reply-To: <5722EA47.80205@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: On 2016/4/29 12:59, Jan Kiszka wrote: > On 2016-04-29 04:09, Yang Zhang wrote: >> On 2016/4/28 23:32, Radim Kr=C4=8Dm=C3=A1=C5=99 wrote: >>> 2016-04-28 08:54+0200, Jan Kiszka: >>>> On 2016-04-28 03:11, Yang Zhang wrote: >>>>> On 2016/4/27 17:45, Jan Kiszka wrote: >>>>>> On 2016-04-27 11:39, Yang Zhang wrote: >>>>>>> I mean in Tianyu's case, if he doesn't care about to deliver ex= ternal >>>>>>> interrupt to CPU >255, IR is not required. >>>>>> >>>>>> What matters is the guest OS. See my other reply on this why thi= s >>>>>> doesn't work, even for Linux. >>>>> >>>>> Since there only few devices in his case, set the irq affinity ma= nually >>>>> is enough. >>> >>> You could configure non-IPIs to work, but we want to create options= that >>> are hard to break. >>> >>>> Ah, wait - are we talking about emulating the Xeon Phi architectur= e in >>>> QEMU, accelerated by KVM? >>> >>> Knights Landing will also be manufactured as a CPU, hopefully witho= ut >>> many peculiarities. >>> >>> I think we are talking about extending KVM's IR-less x2APIC, when >>> standard x2APIC is the future. >> >> Yes, Since IR is only useful for the external device, and 255 CPUs i= s >> enough to handle the interrupts from external devices. Besides, i th= ink >> virtual VT-d will bring extra performance impaction for devices, so = if >> IR-less X2APIC also works well with more than 255 VCPUs, maybe exten= ding >> KVM with IR-less x2apic is not a bad idea. > > IR-less x2APIC for guest architectures that are expected to provide I= R > remains a bad idea, at least until we have hard numbers what this > suspected performance impact actually is. Unless you update IRQ > affinities an insane rates, the impact should not be relevant because > remapping results are cached (for the irqfd hot-path) or you are alre= ady > taking the long way (userspace device emulation). I think it is not only interrupt. There must have the DMAR emulation an= d=20 the cost for DMA is heavy in VM(DMA operations are very frequently). I=20 cannot remember whether there are strong dependency in hardware between= =20 DMAR and IR(I know IR is relying on QI). Even hardware dependency is ok= ,=20 is it ok for OS running in hardware with IR but without DMAR? --=20 best regards yang