From: "Radim Krčmář" <rkrcmar@redhat.com>
To: Igor Mammedov <imammedo@redhat.com>
Cc: Bandan Das <bsd@redhat.com>,
Hardik H Bagdi <hbagdi1@binghamton.edu>,
kvm@vger.kernel.org
Subject: Re: KVM_MAX_VCPU hard limit of 255 on x86
Date: Tue, 5 Apr 2016 16:01:02 +0200 [thread overview]
Message-ID: <20160405140102.GC21537@potion.brq.redhat.com> (raw)
In-Reply-To: <20160405132000.6c2f5ce1@igors-macbook-pro.local>
2016-04-05 13:20+0200, Igor Mammedov:
> On Mon, 4 Apr 2016 22:34:08 +0200
> Radim Krčmář <rkrcmar@redhat.com> 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.
>> >
>> > It should save some boot time due to removing timeout for waiting
>> > APs wakeup.
>>
>> 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?
The spec says that putting all LAPICs into x2APIC mode is firmware's job
(10.12.8.1 Consistency of APIC IDs and CPUID, but we can do it in QEMU).
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.)
prev parent reply other threads:[~2016-04-05 14:01 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-01 21:19 KVM_MAX_VCPU hard limit of 255 on x86 Hardik H Bagdi
2016-04-01 21:55 ` Bandan Das
2016-04-04 15:17 ` Radim Krčmář
2016-04-04 19:14 ` Igor Mammedov
2016-04-04 20:34 ` Radim Krčmář
2016-04-05 11:20 ` Igor Mammedov
2016-04-05 14:01 ` Radim Krčmář [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160405140102.GC21537@potion.brq.redhat.com \
--to=rkrcmar@redhat.com \
--cc=bsd@redhat.com \
--cc=hbagdi1@binghamton.edu \
--cc=imammedo@redhat.com \
--cc=kvm@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.