From mboxrd@z Thu Jan 1 00:00:00 1970 From: Igor Mammedov Subject: Re: KVM_MAX_VCPU hard limit of 255 on x86 Date: Tue, 5 Apr 2016 13:20:00 +0200 Message-ID: <20160405132000.6c2f5ce1@igors-macbook-pro.local> References: <20160404151719.GA21537@potion.brq.redhat.com> <20160404211413.5e5b7264@igors-macbook-pro.local> <20160404203408.GB21537@potion.brq.redhat.com> 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: Radim =?UTF-8?Q?Kr=C4=8Dm=C3=A1=C5=99?= Return-path: Received: from mx1.redhat.com ([209.132.183.28]:51167 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757141AbcDELUK convert rfc822-to-8bit (ORCPT ); Tue, 5 Apr 2016 07:20:10 -0400 In-Reply-To: <20160404203408.GB21537@potion.brq.redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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 them up. I probably miss something but how would firmware be involved in this?