From mboxrd@z Thu Jan 1 00:00:00 1970 From: Radim =?utf-8?B?S3LEjW3DocWZ?= Subject: Re: KVM_MAX_VCPU hard limit of 255 on x86 Date: Tue, 5 Apr 2016 16:01:02 +0200 Message-ID: <20160405140102.GC21537@potion.brq.redhat.com> References: <20160404151719.GA21537@potion.brq.redhat.com> <20160404211413.5e5b7264@igors-macbook-pro.local> <20160404203408.GB21537@potion.brq.redhat.com> <20160405132000.6c2f5ce1@igors-macbook-pro.local> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Bandan Das , Hardik H Bagdi , kvm@vger.kernel.org To: Igor Mammedov Return-path: Received: from mx1.redhat.com ([209.132.183.28]:38459 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753059AbcDEOBG (ORCPT ); Tue, 5 Apr 2016 10:01:06 -0400 Content-Disposition: inline In-Reply-To: <20160405132000.6c2f5ce1@igors-macbook-pro.local> Sender: kvm-owner@vger.kernel.org List-ID: 2016-04-05 13:20+0200, Igor Mammedov: > On Mon, 4 Apr 2016 22:34:08 +0200 > Radim Kr=C4=8Dm=C3=A1=C5=99 wrote: >> 2016-04-04 21:14+0200, Igor Mammedov: >> >> (And firmware doesn't implement x2APIC, and other minor >> >> problems ...) >> > Firmware probably doesn't need more than 1 VCPU, maybe we can >> > get rid of if it enumerating VCPUs via broadcast AP wakeup >> > since it no longer builds ACPI tables anymore. >> >=20 >> > It should save some boot time due to removing timeout for waiting >> > APs wakeup. >>=20 >> Rudimentary x2APIC support is needed, because the OS should get >> control with all LAPICs in x2APIC mode when any APIC ID is over 255. >> We could code that in QEMU to save some time, but I am reluctant to >> move the whole MP initialization before >255 is proven as working. := ) > As you said it's up to OS to get control of all LAPICs, i.e. wake the= m > up. I probably miss something but how would firmware be involved in > this? The spec says that putting all LAPICs into x2APIC mode is firmware's jo= b (10.12.8.1 Consistency of APIC IDs and CPUID, but we can do it in QEMU)= =2E An OS can expect that all LAPICs will be in x2APIC mode, which causes a problem if the firmware didn't switch to x2APIC, because non-broadcast INIT/SIPI to to high APIC IDs would fail. I'm lost now, are we talking about optimizing seabios' smp_setup()? (I think smp_setup touches APs because of SDM, Dec 2015, 8.4.3 MP Initialization Protocol Algorithm for MP Systems, items 6 and 7.)