All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: x86@kernel.org, Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Borislav Petkov <bp@suse.de>, Prarit Bhargava <prarit@redhat.com>,
	linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org
Subject: Re: [PATCH RFC] x86/smpboot: Set safer __max_logical_packages limit
Date: Thu, 20 Apr 2017 18:15:03 +0200	[thread overview]
Message-ID: <20170420161503.vr7nc2czjht7g2v3@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <87fuh3xf2i.fsf@vitty.brq.redhat.com>

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 :-/

  parent reply	other threads:[~2017-04-20 16:15 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-20 13:24 [PATCH RFC] x86/smpboot: Set safer __max_logical_packages limit Vitaly Kuznetsov
2017-04-20 15:06 ` Peter Zijlstra
2017-04-20 15:06 ` Peter Zijlstra
2017-04-20 15:40   ` Vitaly Kuznetsov
2017-04-20 15:40   ` Vitaly Kuznetsov
2017-04-20 16:01     ` [Xen-devel] " Boris Ostrovsky
2017-04-20 16:21       ` Vitaly Kuznetsov
2017-04-20 16:21       ` Vitaly Kuznetsov
2017-04-20 16:01     ` Boris Ostrovsky
2017-04-20 16:15     ` Peter Zijlstra
2017-04-20 16:15     ` Peter Zijlstra [this message]
2017-04-20 17:09       ` Boris Ostrovsky
2017-04-20 17:09       ` [Xen-devel] " Boris Ostrovsky
2017-04-20 17:04   ` Andrew Cooper
2017-04-20 17:04   ` [Xen-devel] " Andrew Cooper
  -- strict thread matches above, loose matches on Subject: below --
2017-04-20 13:24 Vitaly Kuznetsov

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=20170420161503.vr7nc2czjht7g2v3@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=bp@suse.de \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=prarit@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=vkuznets@redhat.com \
    --cc=x86@kernel.org \
    --cc=xen-devel@lists.xenproject.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.