From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S971065AbdDTQPP (ORCPT ); Thu, 20 Apr 2017 12:15:15 -0400 Received: from bombadil.infradead.org ([65.50.211.133]:53787 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S971048AbdDTQPK (ORCPT ); Thu, 20 Apr 2017 12:15:10 -0400 Date: Thu, 20 Apr 2017 18:15:03 +0200 From: Peter Zijlstra To: Vitaly Kuznetsov Cc: x86@kernel.org, Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Borislav Petkov , Prarit Bhargava , linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH RFC] x86/smpboot: Set safer __max_logical_packages limit Message-ID: <20170420161503.vr7nc2czjht7g2v3@hirez.programming.kicks-ass.net> References: <20170420132453.19652-1-vkuznets@redhat.com> <20170420150615.ns3343rokvmc3kjt@hirez.programming.kicks-ass.net> <87fuh3xf2i.fsf@vitty.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87fuh3xf2i.fsf@vitty.brq.redhat.com> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 20, 2017 at 05:40:37PM +0200, Vitaly Kuznetsov wrote: > > This is getting ludicrous. Xen is plain broken, and instead of fixing > > it, you propose to somehow deal with its obviously crack induced > > behaviour :-( > > Totally agree and I don't like the solution I propose (and that's why > this is RFC)... The problem is that there are such Xen setups in the > wild and with the recent changes some guests will BUG() :-( > > Alternatively, we can just remove the BUG() and do something with CPUs > which have their pkg >= __max_logical_packages, e.g. assign them to the > last package. Far from ideal but will help to avoid the regression. So currently none of the stuff that uses this should appear in Xen. Its all drivers for hardware that isn't virtualized (afaik). So assigning to the last package 'works'. But the moment this ends up getting used that explodes, because we'll need different object instances for each piece of hardware. There just isn't a good solution; on the one hand the BIOS is prone to providing crap numbers, on the other hand virt (esp. Xen as it turns out) provides absolutely bonkers/inconsistent topology information. Very frustrating :-/