From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from us-smtp-1.mimecast.com ([205.139.110.61] helo=us-smtp-delivery-1.mimecast.com) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jP56m-0000wX-Pz for kexec@lists.infradead.org; Thu, 16 Apr 2020 14:03:16 +0000 Date: Thu, 16 Apr 2020 22:02:47 +0800 From: Baoquan He Subject: Re: [PATCH 1/3] kexec: Prevent removal of memory in use by a loaded kexec image Message-ID: <20200416140247.GA12723@MiWiFi-R3L-srv> References: <20200413023701.GA20265@MiWiFi-R3L-srv> <871rorjzmc.fsf@x220.int.ebiederm.org> <20200414064031.GB4247@MiWiFi-R3L-srv> <86e96214-7053-340b-5c1a-ff97fb94d8e0@redhat.com> <20200414092201.GD4247@MiWiFi-R3L-srv> <20200414143912.GE4247@MiWiFi-R3L-srv> <0085f460-b0c7-b25f-36a7-fa3bafaab6fe@redhat.com> <20200415023524.GG4247@MiWiFi-R3L-srv> <18cf6afd-c651-25c7-aca3-3ca3c0e07547@redhat.com> MIME-Version: 1.0 In-Reply-To: <18cf6afd-c651-25c7-aca3-3ca3c0e07547@redhat.com> Content-Disposition: inline List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "kexec" Errors-To: kexec-bounces+dwmw2=infradead.org@lists.infradead.org To: David Hildenbrand Cc: piliu@redhat.com, Anshuman Khandual , Catalin Marinas , Bhupesh Sharma , linuxppc-dev@lists.ozlabs.org, kexec@lists.infradead.org, Russell King - ARM Linux admin , linux-mm@kvack.org, James Morse , "Eric W. Biederman" , Andrew Morton , Will Deacon , linux-arm-kernel@lists.infradead.org On 04/16/20 at 03:31pm, David Hildenbrand wrote: > > Not sure if I get the notifier idea clearly. If you mean > > > > 1) Add a common function to pick memory in unmovable zone; > > Not strictly required IMHO. But, minor detail. > > > 2) Let DLPAR, balloon register with notifier; > > Yeah, or virtio-mem, or any other technology that adds/removes memory > dynamically. > > > 3) In the common function, ask notified part to check if the picked > > unmovable memory is available for locating kexec kernel; > > Yeah. These may not be needed, please see below comment. > > > > > Sounds doable to me, and not complicated. > > > >> images. It would apply to > >> > >> - arm64 and filter out all hotadded memory (IIRC, only boot memory can > >> be used). > > > > Do you mean hot added memory after boot can't be recognized and added > > into system RAM on arm64? > > See patch #3 of this patch set, which wants to avoid placing kexec > binaries on hotplugged memory. But I have no idea what the current plan > regarding arm64 is (this thread exploded :) ). > > I would assume that we don't want to place kexec images on any > hotplugged (or rather: hot(un)pluggable) memory - on any architecture. Yes, noticed that and James replied to DaveY. Later, when I was considering to make a draft patch to do the picking of memory from normal zone, and add a notifier, as we discussed at above, I suddenly realized that kexec_file_load doesn't have this issue. It traverse system RAM bottom up to get an available region to put kernel/initrd/boot_param, etc. I can't think of a system where its low memory could be unavailable. > > > > > > >> - powerpc to filter out all LMBs that can be removed (assuming not all > >> memory corresponds to LMBs that can be removed, otherwise we're in > >> trouble ... :) ) > >> - virtio-mem to filter out all memory it added. > >> - hyper-v to filter out partially backed memory blocks (esp. the last > >> memory block it added and only partially backed it by memory). > >> > >> This would make it work for kexec_file_load(), however, I do wonder how > >> we would want to approach that from userspace kexec-tools when handling > >> it from kexec_load(). > > > > Let's make kexec_file_load work firstly. Since this work is only first > > step to make kexec-ed kernel not break memory hotplug. After kexec > > rebooting, the KASLR may locate kernel into hotpluggable area too. > > Can you elaborate how that would work? Well, boot memory can be hotplugged or not after boot, they are marked in uefi tables, the current kexec doesn't save and pass them into 2nd kenrel, when kexec kernel bootup, it need read them and avoid them to randomize kernel into. _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0DC0CC2BB55 for ; Thu, 16 Apr 2020 14:07:06 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 64E572076D for ; Thu, 16 Apr 2020 14:07:04 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="WvUBUgGd"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="DQJjQS4u" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 64E572076D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 4931Hn4BPjzDrgV for ; Fri, 17 Apr 2020 00:07:01 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=redhat.com (client-ip=205.139.110.120; helo=us-smtp-1.mimecast.com; envelope-from=bhe@redhat.com; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: lists.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=WvUBUgGd; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=DQJjQS4u; dkim-atps=neutral Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4931CH3Vs5zDqg5 for ; Fri, 17 Apr 2020 00:03:06 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1587045782; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=mTCnzd2XlgbcxruM8XtC2INeIkYrefeETcNQ6xKyTQc=; b=WvUBUgGdYsWHRUeGoQwxJRy9sWrvdRBUJjUaIyLQrbq/U4wXTECru/Y1Z647KAwqoBwfnS hMWs6quLNoaJ0+9svQYDhbtaE6W+seWLEKkxDSKCRgUjvH77x3d43vVYIXUlUoHyBLIA9J bmWMgwIlXGSrFH1UVFHxw9T4K+nv4fM= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1587045783; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=mTCnzd2XlgbcxruM8XtC2INeIkYrefeETcNQ6xKyTQc=; b=DQJjQS4uf+sxholljzBU/bx3XuHPFf4zuDLxWHaK/A8IHikMRA5Cgtr5WWpGfdhj5uq249 Um1/mJbwtH6tj842msh45FoRSW+jgK3/qU3YBJrPr5nMfJDML7zoEGFj9pSUdyKDNYv3Zx GZT9EwzNuxcujg8aMrkUZ5hRUJHEngU= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-330-PC3eu-rJOkazl1fOhLt66A-1; Thu, 16 Apr 2020 10:02:55 -0400 X-MC-Unique: PC3eu-rJOkazl1fOhLt66A-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 83520190B2A9; Thu, 16 Apr 2020 14:02:53 +0000 (UTC) Received: from localhost (ovpn-12-36.pek2.redhat.com [10.72.12.36]) by smtp.corp.redhat.com (Postfix) with ESMTPS id ACF605C1C5; Thu, 16 Apr 2020 14:02:49 +0000 (UTC) Date: Thu, 16 Apr 2020 22:02:47 +0800 From: Baoquan He To: David Hildenbrand Subject: Re: [PATCH 1/3] kexec: Prevent removal of memory in use by a loaded kexec image Message-ID: <20200416140247.GA12723@MiWiFi-R3L-srv> References: <20200413023701.GA20265@MiWiFi-R3L-srv> <871rorjzmc.fsf@x220.int.ebiederm.org> <20200414064031.GB4247@MiWiFi-R3L-srv> <86e96214-7053-340b-5c1a-ff97fb94d8e0@redhat.com> <20200414092201.GD4247@MiWiFi-R3L-srv> <20200414143912.GE4247@MiWiFi-R3L-srv> <0085f460-b0c7-b25f-36a7-fa3bafaab6fe@redhat.com> <20200415023524.GG4247@MiWiFi-R3L-srv> <18cf6afd-c651-25c7-aca3-3ca3c0e07547@redhat.com> MIME-Version: 1.0 In-Reply-To: <18cf6afd-c651-25c7-aca3-3ca3c0e07547@redhat.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: piliu@redhat.com, Anshuman Khandual , Catalin Marinas , Bhupesh Sharma , linuxppc-dev@lists.ozlabs.org, kexec@lists.infradead.org, Russell King - ARM Linux admin , linux-mm@kvack.org, James Morse , "Eric W. Biederman" , Andrew Morton , Will Deacon , linux-arm-kernel@lists.infradead.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On 04/16/20 at 03:31pm, David Hildenbrand wrote: > > Not sure if I get the notifier idea clearly. If you mean=20 > >=20 > > 1) Add a common function to pick memory in unmovable zone; >=20 > Not strictly required IMHO. But, minor detail. >=20 > > 2) Let DLPAR, balloon register with notifier; >=20 > Yeah, or virtio-mem, or any other technology that adds/removes memory > dynamically. >=20 > > 3) In the common function, ask notified part to check if the picked > > unmovable memory is available for locating kexec kernel; >=20 > Yeah. These may not be needed, please see below comment. >=20 > >=20 > > Sounds doable to me, and not complicated. > >=20 > >> images. It would apply to > >> > >> - arm64 and filter out all hotadded memory (IIRC, only boot memory can > >> be used). > >=20 > > Do you mean hot added memory after boot can't be recognized and added > > into system RAM on arm64? >=20 > See patch #3 of this patch set, which wants to avoid placing kexec > binaries on hotplugged memory. But I have no idea what the current plan > regarding arm64 is (this thread exploded :) ). >=20 > I would assume that we don't want to place kexec images on any > hotplugged (or rather: hot(un)pluggable) memory - on any architecture. Yes, noticed that and James replied to DaveY. Later, when I was considering to make a draft patch to do the picking of memory from normal zone, and add a notifier, as we discussed at above, I suddenly realized that kexec_file_load doesn't have this issue. It traverse system RAM bottom up to get an available region to put kernel/initrd/boot_param, etc. I can't think of a system where its low memory could be unavailable. >=20 > >=20 > >=20 > >> - powerpc to filter out all LMBs that can be removed (assuming not all > >> memory corresponds to LMBs that can be removed, otherwise we're in > >> trouble ... :) ) > >> - virtio-mem to filter out all memory it added. > >> - hyper-v to filter out partially backed memory blocks (esp. the last > >> memory block it added and only partially backed it by memory). > >> > >> This would make it work for kexec_file_load(), however, I do wonder ho= w > >> we would want to approach that from userspace kexec-tools when handlin= g > >> it from kexec_load(). > >=20 > > Let's make kexec_file_load work firstly. Since this work is only first > > step to make kexec-ed kernel not break memory hotplug. After kexec > > rebooting, the KASLR may locate kernel into hotpluggable area too. >=20 > Can you elaborate how that would work? Well, boot memory can be hotplugged or not after boot, they are marked in uefi tables, the current kexec doesn't save and pass them into 2nd kenrel, when kexec kernel bootup, it need read them and avoid them to randomize kernel into. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6243CC352BE for ; Thu, 16 Apr 2020 14:03:25 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 33A9F22250 for ; Thu, 16 Apr 2020 14:03:25 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="XfSpEiDb"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="BtqLPa9a" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 33A9F22250 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=ZBYZvPaVPbx3Al8Jfx0JA/0aLqLtsrVAAA3vubRvBi8=; b=XfSpEiDbM9BUkj ce5Ipub3vhxS+l/INxSPGHWBy+62srWCmfqIoAIfmLyvs5A8Dr0+K0HZdYjxQ/snZqbarCchEKtOT 0SAnHEtdFmPeSX3/bFPGaxq5q3u7T06gp3L/r3/5i+KsvAjhgbQ65BYpSZKURbNDKtyiSgEt082vT A0yzps8NTdqiCU2k8K0AtJWSCzOYQ3INo7v0jIQ6QH7yRfCVVPoHe5XemXO3ncQiWTUXfFiQEEAxB Sd+IZ+aALvP1g8lvMR61/oOUp/Sjf6Z4bmRj4EIcTQ9lm59M3PFwq4NCGrwsIFy+DM09LZB7X3gso VI+1UWuQ7do2nq+OVpbQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jP56v-0001DT-Km; Thu, 16 Apr 2020 14:03:21 +0000 Received: from us-smtp-delivery-1.mimecast.com ([205.139.110.120] helo=us-smtp-1.mimecast.com) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jP56m-0000wW-G1 for linux-arm-kernel@lists.infradead.org; Thu, 16 Apr 2020 14:03:14 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1587045787; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=mTCnzd2XlgbcxruM8XtC2INeIkYrefeETcNQ6xKyTQc=; b=BtqLPa9aoVdgLnkvUmm1kcG23hKzKAyDZAfZ5rV7apEkJ08l7eG2PPoPy0sWxNUWqI6rDk xgo6hAWMnbD3MMDpy5PEmvDoPy33fw4hpP4V4TgKjs+WB0WIuV4aLENpOjIXKmQ5ZymwS8 zxLmIq6sjJ8GeCFiHqryGsmADMOd2P0= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-330-PC3eu-rJOkazl1fOhLt66A-1; Thu, 16 Apr 2020 10:02:55 -0400 X-MC-Unique: PC3eu-rJOkazl1fOhLt66A-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 83520190B2A9; Thu, 16 Apr 2020 14:02:53 +0000 (UTC) Received: from localhost (ovpn-12-36.pek2.redhat.com [10.72.12.36]) by smtp.corp.redhat.com (Postfix) with ESMTPS id ACF605C1C5; Thu, 16 Apr 2020 14:02:49 +0000 (UTC) Date: Thu, 16 Apr 2020 22:02:47 +0800 From: Baoquan He To: David Hildenbrand Subject: Re: [PATCH 1/3] kexec: Prevent removal of memory in use by a loaded kexec image Message-ID: <20200416140247.GA12723@MiWiFi-R3L-srv> References: <20200413023701.GA20265@MiWiFi-R3L-srv> <871rorjzmc.fsf@x220.int.ebiederm.org> <20200414064031.GB4247@MiWiFi-R3L-srv> <86e96214-7053-340b-5c1a-ff97fb94d8e0@redhat.com> <20200414092201.GD4247@MiWiFi-R3L-srv> <20200414143912.GE4247@MiWiFi-R3L-srv> <0085f460-b0c7-b25f-36a7-fa3bafaab6fe@redhat.com> <20200415023524.GG4247@MiWiFi-R3L-srv> <18cf6afd-c651-25c7-aca3-3ca3c0e07547@redhat.com> MIME-Version: 1.0 In-Reply-To: <18cf6afd-c651-25c7-aca3-3ca3c0e07547@redhat.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200416_070312_639553_5C1A64A6 X-CRM114-Status: GOOD ( 22.83 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: piliu@redhat.com, Anshuman Khandual , Catalin Marinas , Bhupesh Sharma , linuxppc-dev@lists.ozlabs.org, kexec@lists.infradead.org, Russell King - ARM Linux admin , linux-mm@kvack.org, James Morse , "Eric W. Biederman" , Andrew Morton , Will Deacon , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 04/16/20 at 03:31pm, David Hildenbrand wrote: > > Not sure if I get the notifier idea clearly. If you mean > > > > 1) Add a common function to pick memory in unmovable zone; > > Not strictly required IMHO. But, minor detail. > > > 2) Let DLPAR, balloon register with notifier; > > Yeah, or virtio-mem, or any other technology that adds/removes memory > dynamically. > > > 3) In the common function, ask notified part to check if the picked > > unmovable memory is available for locating kexec kernel; > > Yeah. These may not be needed, please see below comment. > > > > > Sounds doable to me, and not complicated. > > > >> images. It would apply to > >> > >> - arm64 and filter out all hotadded memory (IIRC, only boot memory can > >> be used). > > > > Do you mean hot added memory after boot can't be recognized and added > > into system RAM on arm64? > > See patch #3 of this patch set, which wants to avoid placing kexec > binaries on hotplugged memory. But I have no idea what the current plan > regarding arm64 is (this thread exploded :) ). > > I would assume that we don't want to place kexec images on any > hotplugged (or rather: hot(un)pluggable) memory - on any architecture. Yes, noticed that and James replied to DaveY. Later, when I was considering to make a draft patch to do the picking of memory from normal zone, and add a notifier, as we discussed at above, I suddenly realized that kexec_file_load doesn't have this issue. It traverse system RAM bottom up to get an available region to put kernel/initrd/boot_param, etc. I can't think of a system where its low memory could be unavailable. > > > > > > >> - powerpc to filter out all LMBs that can be removed (assuming not all > >> memory corresponds to LMBs that can be removed, otherwise we're in > >> trouble ... :) ) > >> - virtio-mem to filter out all memory it added. > >> - hyper-v to filter out partially backed memory blocks (esp. the last > >> memory block it added and only partially backed it by memory). > >> > >> This would make it work for kexec_file_load(), however, I do wonder how > >> we would want to approach that from userspace kexec-tools when handling > >> it from kexec_load(). > > > > Let's make kexec_file_load work firstly. Since this work is only first > > step to make kexec-ed kernel not break memory hotplug. After kexec > > rebooting, the KASLR may locate kernel into hotpluggable area too. > > Can you elaborate how that would work? Well, boot memory can be hotplugged or not after boot, they are marked in uefi tables, the current kexec doesn't save and pass them into 2nd kenrel, when kexec kernel bootup, it need read them and avoid them to randomize kernel into. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.4 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 46242C352BE for ; Thu, 16 Apr 2020 14:03:07 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E51C820786 for ; Thu, 16 Apr 2020 14:03:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="Jam1SKMc" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E51C820786 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 49EA98E00AF; Thu, 16 Apr 2020 10:03:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 44FC98E0001; Thu, 16 Apr 2020 10:03:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 365B28E00AF; Thu, 16 Apr 2020 10:03:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0126.hostedemail.com [216.40.44.126]) by kanga.kvack.org (Postfix) with ESMTP id 183738E0001 for ; Thu, 16 Apr 2020 10:03:06 -0400 (EDT) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id BCEC12493 for ; Thu, 16 Apr 2020 14:03:05 +0000 (UTC) X-FDA: 76713884730.23.chair86_724348b42ff2b X-HE-Tag: chair86_724348b42ff2b X-Filterd-Recvd-Size: 5894 Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by imf01.hostedemail.com (Postfix) with ESMTP for ; Thu, 16 Apr 2020 14:03:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1587045784; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=mTCnzd2XlgbcxruM8XtC2INeIkYrefeETcNQ6xKyTQc=; b=Jam1SKMc7aIaWkfVIl0Eomis2hQmNl/0/cH0QtPODCZMkrA45PSchrcAeC+LFcKgrH9I33 cTvjtuYjq0t8J9P3QQIDkxVS0KCs4GCA3ZI2HDUyn0IYCO4MA+Gel29q4Dm4G3B7rA894h sFxI6blh4mNmaOzNPmqkyLgCaOV+m2Q= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-330-PC3eu-rJOkazl1fOhLt66A-1; Thu, 16 Apr 2020 10:02:55 -0400 X-MC-Unique: PC3eu-rJOkazl1fOhLt66A-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 83520190B2A9; Thu, 16 Apr 2020 14:02:53 +0000 (UTC) Received: from localhost (ovpn-12-36.pek2.redhat.com [10.72.12.36]) by smtp.corp.redhat.com (Postfix) with ESMTPS id ACF605C1C5; Thu, 16 Apr 2020 14:02:49 +0000 (UTC) Date: Thu, 16 Apr 2020 22:02:47 +0800 From: Baoquan He To: David Hildenbrand Cc: "Eric W. Biederman" , Russell King - ARM Linux admin , Anshuman Khandual , Catalin Marinas , Bhupesh Sharma , kexec@lists.infradead.org, linux-mm@kvack.org, James Morse , Andrew Morton , Will Deacon , linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, piliu@redhat.com Subject: Re: [PATCH 1/3] kexec: Prevent removal of memory in use by a loaded kexec image Message-ID: <20200416140247.GA12723@MiWiFi-R3L-srv> References: <20200413023701.GA20265@MiWiFi-R3L-srv> <871rorjzmc.fsf@x220.int.ebiederm.org> <20200414064031.GB4247@MiWiFi-R3L-srv> <86e96214-7053-340b-5c1a-ff97fb94d8e0@redhat.com> <20200414092201.GD4247@MiWiFi-R3L-srv> <20200414143912.GE4247@MiWiFi-R3L-srv> <0085f460-b0c7-b25f-36a7-fa3bafaab6fe@redhat.com> <20200415023524.GG4247@MiWiFi-R3L-srv> <18cf6afd-c651-25c7-aca3-3ca3c0e07547@redhat.com> MIME-Version: 1.0 In-Reply-To: <18cf6afd-c651-25c7-aca3-3ca3c0e07547@redhat.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 04/16/20 at 03:31pm, David Hildenbrand wrote: > > Not sure if I get the notifier idea clearly. If you mean=20 > >=20 > > 1) Add a common function to pick memory in unmovable zone; >=20 > Not strictly required IMHO. But, minor detail. >=20 > > 2) Let DLPAR, balloon register with notifier; >=20 > Yeah, or virtio-mem, or any other technology that adds/removes memory > dynamically. >=20 > > 3) In the common function, ask notified part to check if the picked > > unmovable memory is available for locating kexec kernel; >=20 > Yeah. These may not be needed, please see below comment. >=20 > >=20 > > Sounds doable to me, and not complicated. > >=20 > >> images. It would apply to > >> > >> - arm64 and filter out all hotadded memory (IIRC, only boot memory can > >> be used). > >=20 > > Do you mean hot added memory after boot can't be recognized and added > > into system RAM on arm64? >=20 > See patch #3 of this patch set, which wants to avoid placing kexec > binaries on hotplugged memory. But I have no idea what the current plan > regarding arm64 is (this thread exploded :) ). >=20 > I would assume that we don't want to place kexec images on any > hotplugged (or rather: hot(un)pluggable) memory - on any architecture. Yes, noticed that and James replied to DaveY. Later, when I was considering to make a draft patch to do the picking of memory from normal zone, and add a notifier, as we discussed at above, I suddenly realized that kexec_file_load doesn't have this issue. It traverse system RAM bottom up to get an available region to put kernel/initrd/boot_param, etc. I can't think of a system where its low memory could be unavailable. >=20 > >=20 > >=20 > >> - powerpc to filter out all LMBs that can be removed (assuming not all > >> memory corresponds to LMBs that can be removed, otherwise we're in > >> trouble ... :) ) > >> - virtio-mem to filter out all memory it added. > >> - hyper-v to filter out partially backed memory blocks (esp. the last > >> memory block it added and only partially backed it by memory). > >> > >> This would make it work for kexec_file_load(), however, I do wonder ho= w > >> we would want to approach that from userspace kexec-tools when handlin= g > >> it from kexec_load(). > >=20 > > Let's make kexec_file_load work firstly. Since this work is only first > > step to make kexec-ed kernel not break memory hotplug. After kexec > > rebooting, the KASLR may locate kernel into hotpluggable area too. >=20 > Can you elaborate how that would work? Well, boot memory can be hotplugged or not after boot, they are marked in uefi tables, the current kexec doesn't save and pass them into 2nd kenrel, when kexec kernel bootup, it need read them and avoid them to randomize kernel into.