Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751762AbcLEQC5 (ORCPT ); Mon, 5 Dec 2016 11:02:57 -0500 Received: from mx1.redhat.com ([209.132.183.28]:55876 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751451AbcLEQCc (ORCPT ); Mon, 5 Dec 2016 11:02:32 -0500 Date: Mon, 5 Dec 2016 17:02:29 +0100 From: Radim =?utf-8?B?S3LEjW3DocWZ?= To: David Hildenbrand Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Paolo Bonzini , Igor Mammedov Subject: Re: [PATCH 4/4] KVM: x86: allow hotplug of VCPU with APIC ID over 0xff Message-ID: <20161205160228.GA8660@potion> References: <20161202194401.10038-1-rkrcmar@redhat.com> <20161202194401.10038-5-rkrcmar@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Mon, 05 Dec 2016 16:02:32 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1345 Lines: 29 2016-12-05 15:37+0100, David Hildenbrand: > Am 02.12.2016 um 20:44 schrieb Radim Krčmář: >> LAPIC after reset is in xAPIC mode, which poses a problem for hotplug of >> VCPUs with high APIC ID, because reset VCPU is waiting for INIT/SIPI, >> but there is no way to uniquely address it using xAPIC. >> >> From many possible options, we chose the one that also works on real >> hardware: accepting interrupts addressed to LAPIC's x2APIC ID even in >> xAPIC mode. >> >> KVM intentionally differs from real hardware, because real hardware >> (Knights Landing) does just "x2apic_id & 0xff" to decide whether to >> accept the interrupt in xAPIC mode and it can deliver one interrupt to >> more than one physical destination, e.g. 0x123 to 0x123 and 0x23. >> >> Add a capability to let userspace know that we do something now. > > Should we allow user space to turn it on/off for compatibility handling? Or > do we just not care? There should be no guest that relies on the previous behavior, so I'd forgo the toggle, because it would be extra conditions in the code. I'd add it as a flag to KVM_CAP_X2APIC_API if you have reasons to let userspace choose. > (or how will this capability be used later on?) New userspace should check this capability and disable hotplug of VCPUs with id over 255 if KVM doesn't support it.