Received: by 2002:a05:6a10:2785:0:0:0:0 with SMTP id ia5csp7588pxb; Tue, 12 Jan 2021 18:17:30 -0800 (PST) X-Google-Smtp-Source: ABdhPJz910pmYS/qaL/BUBx13ur5fHSWvVIOJCyhhYuKG9kAg7gWmRcB9TuZickh+fBF5o3PoBhu X-Received: by 2002:a17:906:60c3:: with SMTP id f3mr1187358ejk.65.1610504249817; Tue, 12 Jan 2021 18:17:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610504249; cv=none; d=google.com; s=arc-20160816; b=awtxUeoed84WR3M4QPDIyz/oUGtNjyVkCvLoWmIQQiwf3Htb7hRv7tgrMKLyYrNA65 GUiR6c3HhFJP2uEqOQp8grzFyIzxO5ftw0X6Ahlj0ArHg9+iPKCENJxcNItGZrbq3CD8 MuEt3yOP+pfCIXCrWcLm3TWjUAJLver2DxGfrqtF3XToK3kDnomYj1Y1cDXkt8nAWMge Z9RIbpFCjH6TgBsTHmgyf4sAGiDD5BWtBUl74S3ecg05BipqsfnGP5GDC8YvL9itYq5j W0THfanXb094JqbYqcVLqNza9hZk55XKYPjrQ/cAtN/n0scJPjXFZi9nx+2am37LMLw6 1T+A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=AjPCDGO5Tp5bG6E6D23n/NTNaWQQ3KALty8JuQcW/Zs=; b=gYWUvxJYF189ykO4rbMwPkWZCMpd1B5jC+JgNrY4p14ofE7cjm1rtwURz1GwJI4kOe fY1+nDDp4gbVy+IC9L90pKIH2nw8Rvx+Snm+mMvm0KiYyazh/iOpAPIlDfP5u+5T7rni 1jSfLgrsu4eenu0P6iwg2HdigStKv8e00U9WgN176krmR9PkDCntxmCI+tfjlvZuT8Jr V/cV6IH4/PAMib1+/jiVZ1ejcuDu1pPiSjhRMg3ykPJBBjxJQKR5rjOYsYKHPEUwDxnv /kYTVWbQtzmo75y8hwq0DoINbeg6W8NEJHpwH2c74Rg8x3wSt5W52UHrj/fKmVBot1xc NjvQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=RUb+nLf4; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q13si271640edd.419.2021.01.12.18.17.05; Tue, 12 Jan 2021 18:17:29 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=RUb+nLf4; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391375AbhALPyc (ORCPT + 99 others); Tue, 12 Jan 2021 10:54:32 -0500 Received: from mail.kernel.org ([198.145.29.99]:46582 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729490AbhALPya (ORCPT ); Tue, 12 Jan 2021 10:54:30 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id B91452070E; Tue, 12 Jan 2021 15:53:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1610466830; bh=AjPCDGO5Tp5bG6E6D23n/NTNaWQQ3KALty8JuQcW/Zs=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=RUb+nLf4tJSqUEj58my4Ysq0kiNEt6yHW+nKlPwlW42bSC57doYy0waj3OANYL4uK g6fIwgWcN5RWzUsf2XpX2IxLf/Q+ZJGKrKsRlkBu+q2biJjw2pEXUdtj2KCOUUbIfr RD24bKBn8Myeo7mnqE5e2zqP+H3m4/2SX2/aGzZFJnyfpvhGr/sVDrOE/RkZMn7sd+ ZkNA7PlbITTtNUVopdfJAq6H9X8noDjQ0WMJjoOWfUHGeYAsa7XGKWXtWJ6gI/X+hv 4vtj3IYi9yE1WZP2xvTcyKTAU0V+MAp8eqJWxxpopQjD9Aw6lG8BMHiukblwyMBV3g Twm7ccV8LnipA== Received: by mail-ed1-f47.google.com with SMTP id w10so1925626edu.5; Tue, 12 Jan 2021 07:53:49 -0800 (PST) X-Gm-Message-State: AOAM530ZueZqDZ0N0sPgo+pQBynFwh6MjSbskR4glCTSZ6P5fSmiSS5+ MBsqMRTDY4HxVHZ6LIbHLTB1DDnFToGyjzHWPA== X-Received: by 2002:a50:e78b:: with SMTP id b11mr3857477edn.165.1610466828133; Tue, 12 Jan 2021 07:53:48 -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 09:53:36 -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 Cc: Catalin Marinas , Will Deacon , Marc Zyngier , James Morse , Julien Thierry , Suzuki K Poulose , Frank Rowand , devicetree@vger.kernel.org, android-kvm@google.com, "linux-kernel@vger.kernel.org" , Android Kernel Team , "open list:KERNEL VIRTUAL MACHINE FOR ARM64 (KVM/arm64)" , linux-arm-kernel , Fuad Tabba , Mark Rutland , David Brazdil Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. Rob