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=-4.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 F1609C433E0 for ; Tue, 12 Jan 2021 16:48:09 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 981CA23117 for ; Tue, 12 Jan 2021 16:48:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 981CA23117 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+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=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=vdbqEZAP7NJMK+5K0fDQzS7k54So6L96NvXesx9af/U=; b=OHncK+ZHIFZu2Kdza2833JPiM /OI4vAI1tecuyxcptbg+fsgYlbDsfao2Li150CUG8yz32+gXTZ8GE91lT1VN54FxYEjmWJ8Rk6OBp AFb4HK+6SYtW9T9qP6SQqnwcl3zC9d78KWRfBr2vYBBJfuE0N/ZB759ELS0iys386Yd+i97fd8OZg szBMudEbc9rmLAjTecfOrDSkwxv8FfXkLB7beSve5BWSyT7DR+em3Mw8QzKWXHu73CRaRpCj5QdXX lYgfmh9lXDpHF6lLqcmagur3jQlbgB3Oy2PIMMRLQb3wJboDVAoJJopvKs4qFY0oL+ENbh7VPC7H1 uhdG443Fg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kzMoE-0001mH-HC; Tue, 12 Jan 2021 16:46:18 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kzMo7-0001kj-QZ for linux-arm-kernel@lists.infradead.org; Tue, 12 Jan 2021 16:46:17 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 7FADA2311D for ; Tue, 12 Jan 2021 16:46:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1610469970; bh=G8QgmioLPowngS9PnWyS0qJ4GW5plz/qHFNOJiaPmLM=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=utv8poqFkjEP20anauzkLWewiDee9vsGsy6vyLsmr3EPv7IlXm1g/fNO0INTpvRm1 v2PgImEiKX8ztyABczzpBOEhbzIyaJpAccHLb8IFEW20WPjtZQFRKzdvQh24GDVYXF QuOrbf+4HF22PlWuAsAGgo7uxImKpfLnfNIMp63kcHLBVpAqkMg0JoW9xDlto6ZL4f dr9likG3mnT/AFbPWPkR+C/qxNxQ4CLS9lsSaOTfi0RyVGFDEGYp/mFrN3GUXVI+tz CVbb5KMFAirL9ETDQiHejG2L/6L62nC5eHgxduPHFT6jesN0HpHTDuzM+nFwhw3rRt 6dDhJZqR7ju3A== Received: by mail-ej1-f41.google.com with SMTP id w1so4415357ejf.11 for ; Tue, 12 Jan 2021 08:46:10 -0800 (PST) X-Gm-Message-State: AOAM530i00F1n761OItXqAicuNc3yELGxrMsI2B9R3F1i5eomcoJ0yYN bW3JJx84PKpwss6g8fDOUYVf0c0gcp1zOfU9nQ== X-Google-Smtp-Source: ABdhPJwpatqtscFinSdtYUrvRElGEmeizOIFHtAttZVKAEASK6GUt12WCxKJxKuZKsgMiopOcpPvL1kPhiZ1kgVNx0g= X-Received: by 2002:a17:906:ae43:: with SMTP id lf3mr3526825ejb.130.1610469968932; Tue, 12 Jan 2021 08:46:08 -0800 (PST) MIME-Version: 1.0 References: <20210108121524.656872-1-qperret@google.com> <20210108121524.656872-16-qperret@google.com> In-Reply-To: From: Rob Herring Date: Tue, 12 Jan 2021 10:45:56 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH v2 15/26] of/fdt: Introduce early_init_dt_add_memory_hyp() To: Quentin Perret X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210112_114612_049198_A346E8BB X-CRM114-Status: GOOD ( 31.70 ) 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: Mark Rutland , devicetree@vger.kernel.org, Android Kernel Team , Frank Rowand , Suzuki K Poulose , android-kvm@google.com, Catalin Marinas , Fuad Tabba , "linux-kernel@vger.kernel.org" , James Morse , linux-arm-kernel , Marc Zyngier , David Brazdil , Will Deacon , "open list:KERNEL VIRTUAL MACHINE FOR ARM64 \(KVM/arm64\)" , Julien Thierry Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Jan 12, 2021 at 10:15 AM Quentin Perret wrote: > > On Tuesday 12 Jan 2021 at 09:53:36 (-0600), Rob Herring wrote: > > On Tue, Jan 12, 2021 at 8:26 AM Quentin Perret wrote: > > > > > > On Tuesday 12 Jan 2021 at 08:10:47 (-0600), Rob Herring wrote: > > > > On Tue, Jan 12, 2021 at 3:51 AM Quentin Perret wrote: > > > > > > > > > > On Monday 11 Jan 2021 at 08:45:10 (-0600), Rob Herring wrote: > > > > > > On Fri, Jan 8, 2021 at 6:16 AM Quentin Perret wrote: > > > > > > > > > > > > > > Introduce early_init_dt_add_memory_hyp() to allow KVM to conserve a copy > > > > > > > of the memory regions parsed from DT. This will be needed in the context > > > > > > > of the protected nVHE feature of KVM/arm64 where the code running at EL2 > > > > > > > will be cleanly separated from the host kernel during boot, and will > > > > > > > need its own representation of memory. > > > > > > > > > > > > What happened to doing this with memblock? > > > > > > > > > > I gave it a go, but as mentioned in v1, I ran into issues for nomap > > > > > regions. I want the hypervisor to know about these memory regions (it's > > > > > possible some of those will be given to protected guests for instance) > > > > > but these seem to be entirely removed from the memblocks when using DT: > > > > > > > > > > https://elixir.bootlin.com/linux/latest/source/drivers/of/fdt.c#L1153 > > > > > > > > > > EFI appears to do things differently, though, as it 'just' uses > > > > > memblock_mark_nomap() instead of actively removing the memblock. And that > > > > > means I could actually use the memblock API for EFI, but I'd rather > > > > > have a common solution. I tried to understand why things are done > > > > > differently but couldn't find an answer and kept things simple and > > > > > working for now. > > > > > > > > > > Is there a good reason for not using memblock_mark_nomap() with DT? If > > > > > not, I'm happy to try that. > > > > > > > > There were 2 patches to do that, but it never got resolved. See here[1]. > > > > > > Thanks. So the DT stuff predates the introduction of memblock_mark_nomap, > > > that's why... > > > > > > By reading the discussions, [1] still looks a sensible patch on its own, > > > independently from the issue Nicolas tried to solve. Any reason for not > > > applying it? > > > > As I mentioned in the thread, same patch with 2 different reasons. So > > I just wanted a better commit message covering both. > > Sorry if I'm being thick, but I'm not seeing it. How are they the same? > IIUC, as per Nicolas' last reply, using memblock_mark_nomap() does not > solve his issue with a broken DT. These 2 patches address two completely > separate issues no? Umm, yes you are right. But both are dealing with nomap. So someone needs to sort out what the right thing to do here is. No one cared enough to follow up in a year and a half. Rob _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel