Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp2290185ybb; Thu, 2 Apr 2020 17:28:45 -0700 (PDT) X-Google-Smtp-Source: APiQypKeaW63WeNx/Wv0VtTtzTmC+lLglnDgda8ZKBBZ4Ez1RkEWNwvk7CMu/8aivb7Ycj9b4Pk7 X-Received: by 2002:a4a:d746:: with SMTP id h6mr4795030oot.21.1585873725531; Thu, 02 Apr 2020 17:28:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585873725; cv=none; d=google.com; s=arc-20160816; b=xiN5bMPCmqJNx68/Qnv9M3DHjXhVkk5P4zucMkzY3770mkS9LZXk7LQ777FZwfro3S Ilrvc/rt6VC6fS76aW3N7/1a25c96HyDFfclTA0+dYDAWe87ZBV3KsLQ8NH0iYWIXbCO AaCddDpS2iDCXIQazqu7NWMBqfwJ+lBfNZzH2t5T+2JRVKC/TO2cQR27k/e0TNTbAW0+ TR0a560oYtnbiBQ0CHyOoxn5yHYspU5aJI2/DASEdblMX1e5BetmsfWKh7HAZYXna72w 9ClzkAIbKIbgy7bkuixspOkQBY9nG/FbPbKksq166zV+ftz+dXioYjI230qfEOrwBsOR VgGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=jmXWSnZFrGmmooR0jk9MQKfEVRvqr4Bhu0RmJo6EKnI=; b=neYZAAD7f5wN6MGKoKxsQ1zOfZPqbwHV6LXQBw8eM9i+BC9oCwGJb/psE2RzFQY1qA 1zVt87x/xUNrSbLQQv54olj3fh+ukCxKP3ApSSOjMGBi9eoLoZexuVyEeNkfM8tTfz3Q Dsl6TDSbNFS140jJDI1JACJ+TRv84V9ZE94zdkRbANVH5ZfJbnrfkJ3vBYx3BLWcaYMl ouPYYQfDWLyQODmjSGAJwLoIvqVowe3iD8lOfmE6VPgJ2QjTks5iMYZBGQAIMYe8FJ3A 5bvfy7i+XaZJknSMOK/gAusstGL5/z1n8EsDlcB2U3o86fkVqZCc8DA1IyGYfkXXeB4z pZfg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=RU7KK9hh; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h14si3078401otk.294.2020.04.02.17.28.24; Thu, 02 Apr 2020 17:28:45 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=RU7KK9hh; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390214AbgDBXbk (ORCPT + 99 others); Thu, 2 Apr 2020 19:31:40 -0400 Received: from mail-il1-f194.google.com ([209.85.166.194]:33663 "EHLO mail-il1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2390172AbgDBXbk (ORCPT ); Thu, 2 Apr 2020 19:31:40 -0400 Received: by mail-il1-f194.google.com with SMTP id k29so5476839ilg.0 for ; Thu, 02 Apr 2020 16:31:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jmXWSnZFrGmmooR0jk9MQKfEVRvqr4Bhu0RmJo6EKnI=; b=RU7KK9hhnWQJ37k68Oi3oIEBbXk/64ZO2mh73lxhk7GTlRqey4MxSgxLfvF3eU4HqV +t+7bc0tVqKgfh06b3PP78MbdPAsUHqAtLBknJWTZ8RvMmDjpI/v1Vch4E7CJCZPyA63 L3XUGRqhzy0Hx4URAzBCSIn/0sV4q/oM/C7hExlaNjLGXTCVc4dG1qceJvhiqFEm/UYC NYLs0iA9ZC9+lP+5dWVwBJCQ/Y2Ee9kCnAxXWVue+h1ynLNzgC6POAuoC2qo1VMHX72D X7r73yxULfTxkMLLEsjFzcU1jpbimQTZtMyilSANjjyIRHnfCL03W5cABR2zVVWi8suK Bnxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jmXWSnZFrGmmooR0jk9MQKfEVRvqr4Bhu0RmJo6EKnI=; b=R+zrzOA6OdWL8wlng7/x6tG5hGKiSsE9YO6XjMQWoKLB8/yi5TXsivTfAAPDRT6Vmw DEjcaS2adN0rjgcdOpbrWwQxIq9b2qX8ECWEhvvPoOkc9W8TVegeBvMgd4nAEXkwfIQF DLitXCza9FAskyJwSBcjJVe43n1HPEWUU5fBYRFl2A32qC0r0b3V8qWHMuBI8fOuOYMP u2GCVSDHKmxWihkXUx4N9/02P52wqyUeiPt8xAe3t4nqUZ4foRYsiPYc293p70C5lIaJ 9SDK+N0LoZP9sKGjK7nkHL9IsLG4CgtBtJq/vbJH6zbGkHaZQpX1CZYMT0lncUJwPJvp ZdYA== X-Gm-Message-State: AGi0PubXIosoemfP6CaZVm4NqdK5chuRryXeeW/4wcmxjwVpEPs9FP9V kJGYEr4lwlaMahAtm0lcKIQouHoqCLLLi8axxEg= X-Received: by 2002:a92:39cc:: with SMTP id h73mr5683281ilf.298.1585870299305; Thu, 02 Apr 2020 16:31:39 -0700 (PDT) MIME-Version: 1.0 References: <20200402195156.626430-1-leonardo@linux.ibm.com> <6b4a4a0d4f7af723d0a5a12f4267717a507ce3f0.camel@linux.ibm.com> In-Reply-To: <6b4a4a0d4f7af723d0a5a12f4267717a507ce3f0.camel@linux.ibm.com> From: "Oliver O'Halloran" Date: Fri, 3 Apr 2020 10:31:28 +1100 Message-ID: Subject: Re: [PATCH v3 1/1] powerpc/kernel: Enables memory hot-remove after reboot on pseries guests To: Leonardo Bras Cc: Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Thomas Gleixner , Nathan Fontenot , Greg Kroah-Hartman , Allison Randal , Bharata B Rao , Claudio Carvalho , Hari Bathini , linuxppc-dev , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 3, 2020 at 10:07 AM Leonardo Bras wrote: > > Hello Oliver, thank you for the feedback. > Comments inline: > > On Fri, 2020-04-03 at 09:46 +1100, Oliver O'Halloran wrote: > > > > I don't really understand why the flag is needed at all. According to > > PAPR any memory provided by dynamic reconfiguration can be hot-removed > > so why aren't we treating all DR memory as hot removable? The only > > memory guaranteed to be there 100% of the time is what's in the > > /memory@0 node since that's supposed to cover the real mode area. > > All LMBs are listed in DR memory, even the base memory. > > The v1 of the patch would work this way, as qemu would configure it's > DR memory with (DRC_INVALID | RESERVED) flags and the hot-added memory > with (ASSIGNED) flag. Looking for assigned flag would be enough. > > But as of today, PowerVM doesn't seem to work that way. > When you boot a PowerVM virtual machine with Linux, all memory is added > with the same flags (ASSIGNED). > > To create a solution that doesn't break PowerVM, this new flag was made > necessary. I'm still not convinced it's necessary. Why not check memory@0 and use the size as a clip level? Any memory above that level gets marked as hotpluggable and anything below doesn't. Seems to me that would work on all current platforms, so what am I missing here? > > Best regards, > Leonardo Bras