From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S945453AbdDTRLG (ORCPT ); Thu, 20 Apr 2017 13:11:06 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:17516 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S944828AbdDTRLC (ORCPT ); Thu, 20 Apr 2017 13:11:02 -0400 Subject: Re: [Xen-devel] [PATCH RFC] x86/smpboot: Set safer __max_logical_packages limit To: Peter Zijlstra , Vitaly Kuznetsov References: <20170420132453.19652-1-vkuznets@redhat.com> <20170420150615.ns3343rokvmc3kjt@hirez.programming.kicks-ass.net> <87fuh3xf2i.fsf@vitty.brq.redhat.com> <20170420161503.vr7nc2czjht7g2v3@hirez.programming.kicks-ass.net> Cc: Prarit Bhargava , x86@kernel.org, linux-kernel@vger.kernel.org, Ingo Molnar , "H. Peter Anvin" , xen-devel@lists.xenproject.org, Thomas Gleixner , Borislav Petkov , Juergen Gross From: Boris Ostrovsky Message-ID: Date: Thu, 20 Apr 2017 13:09:43 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170420161503.vr7nc2czjht7g2v3@hirez.programming.kicks-ass.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Source-IP: userv0021.oracle.com [156.151.31.71] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/20/2017 12:15 PM, Peter Zijlstra wrote: > 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. This already gets used. I don't remember details but we had to fix something due to RAPL code referencing topology info (and yes, there is no reason for a guest to use RAPL, but we shouldn't crash neither) > > 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 :-/ > So we might need a way to bypass topology discovery and present some sort of default topology (single package, or 1 CPU per package, for example) and ignore APICID and all that. -boris