From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f53.google.com (mail-ej1-f53.google.com [209.85.218.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E0D401272BD for ; Tue, 5 Mar 2024 15:31:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709652666; cv=none; b=jZ3PGlaF8hvGJ9WKaO3x7C3doyqNllAEh2NU7kMJGoZSMCvsUt8lMppw8sqG7kfVP5UZp8JItw0nop/yju4D6cPS3cxrnXh6h7gYwloIbpF7jqZXaXASiLHrpKLDfhHsUqax45rkljhH8on2ZusUyfEf6CWROKDLEnqRsVuB0dE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709652666; c=relaxed/simple; bh=MWZtdpDzT5uBPJyCi2jictePKr8MSUwQEsy7awmiRSk=; h=Date:From:To:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=gikwTriGdpKS9TrFi8PDIt6QK1F2OJeFnV+p+7hDP8p/Mzg6pvOa05ttCzXL8vGsB4leZkBgdHTpm03tMXLnACNqqe2Wtcu+8MJa7GZtAAWVrAUraipVYaXFr5GDXOJmm+yAmlphbXNrMiKHuwSsg+rTz6idvayeVOjwrOrmysI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=xLwI3aAA; arc=none smtp.client-ip=209.85.218.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="xLwI3aAA" Received: by mail-ej1-f53.google.com with SMTP id a640c23a62f3a-a4429c556efso785696866b.0 for ; Tue, 05 Mar 2024 07:31:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1709652663; x=1710257463; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=jFBfmrcURu1fWMu57pWuFBzvegWbvE+xd+YhP2c5sxY=; b=xLwI3aAASQ/kN2EtnsfQLg2xlGzdpC5Uc70sST2xDkI7u+SAr/txIwyCaRifaZoWIP k+C1ChlT0PYX9yz5eImu2g4FIH22Ko6mbUFBPtrkUXXTwDw7ibNJuPZrnr+bU/YjcLQk vPlIH6tW6Hiyx10fBWwU5wleUVHT0mRAwYaIbnwfE61WkE2XenKUwxloU/S4Gp1AP7B/ UxOFpiKPi2Qdfg3/C5ZAMmyDJ7O5ylKPpqMetNFvC6Ja2ZhAmJ8x2MvmDnjtauPIhRdh DZt2/7QPQP3Kz0PfH0Xlcr2LEZ2bgEJUZfcjPHOdU/yerwyJbw4ctpTKF1DzJWcoHEMT ziCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709652663; x=1710257463; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=jFBfmrcURu1fWMu57pWuFBzvegWbvE+xd+YhP2c5sxY=; b=L5dVnuQx4FPXLSAabGjek41/XQuGvdiCEEiR32GEgDAPAY/LQslYuhZ4RyJOvvACbg /CHzVNODL4DwRJrwMJStZjwUTNwhlHEwH3UUOdxilo6JMFvm4iXEGSjRSrYR6mhcVLV7 SYKMYXKBbpWFYbl88CcynsPv9xZ9M5rYGNO993BYzL8VtnuCuBrFxvQ6+VE95+zqK6jn CPUOhzEpe6iL90BFBicmOuVHsIZAe8TodRnx/RePYON19jINQNnhYiXfzZe+bcIcQ9h/ sUmmcRxlYcx3gXM8MDqhSoe0Va+uaQ59c4QVQBHvtHiDtKEOGk7MZDgvpdApujnSaSbt bDfg== X-Forwarded-Encrypted: i=1; AJvYcCVR43/6dDOhRCIDJSzJOlF4bqB4fyAFsWIJLOF+2+qgPtkq5IQiSAFuWCk6TvmQSQy3NzosQMG+M4u214Hq1Imnv7kOFlMNCcu8EvScvA== X-Gm-Message-State: AOJu0YzqjhbVAiELem96xh+yER1Nk5p56Zm8zWHs0NB87wGTQeUym6RV //5w4TgbdI/i7uVGfxQJA8f4KUNgJl7UZnJ2MTbPGLZ9+Bdp9TUnE8CmTZ5F6Q== X-Google-Smtp-Source: AGHT+IG865qowYD6hypu+joiq3mkfJptCDN2wk6XWC4gZD4eKgj4/V+czQN2m8CgWrMksvV0eTX+4A== X-Received: by 2002:a17:906:4148:b0:a44:f89:a04e with SMTP id l8-20020a170906414800b00a440f89a04emr9475926ejk.35.1709652663164; Tue, 05 Mar 2024 07:31:03 -0800 (PST) Received: from google.com (64.227.90.34.bc.googleusercontent.com. [34.90.227.64]) by smtp.gmail.com with ESMTPSA id bw16-20020a170906c1d000b00a3fb9f1f10csm6146724ejb.161.2024.03.05.07.31.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Mar 2024 07:31:02 -0800 (PST) Date: Tue, 5 Mar 2024 15:30:58 +0000 From: Quentin Perret To: Christoph Hellwig , Will Deacon , Chris Goldsworthy , Android KVM , Patrick Daly , Alex Elder , Srinivas Kandagatla , Murali Nalajal , Trilok Soni , Srivatsa Vaddagiri , Carl van Schaik , Philip Derrin , Prakruthi Deepak Heragu , Jonathan Corbet , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Catalin Marinas , Konrad Dybcio , Bjorn Andersson , Dmitry Baryshkov , Fuad Tabba , Sean Christopherson , Andrew Morton , linux-arm-msm@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org Subject: Re: Re: Re: [PATCH v17 19/35] arch/mm: Export direct {un,}map functions Message-ID: References: <20240222-gunyah-v17-0-1e9da6763d38@quicinc.com> <20240222-gunyah-v17-19-1e9da6763d38@quicinc.com> <20240223071006483-0800.eberman@hu-eberman-lv.qualcomm.com> <20240304094828133-0800.eberman@hu-eberman-lv.qualcomm.com> Precedence: bulk X-Mailing-List: linux-arm-msm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240304094828133-0800.eberman@hu-eberman-lv.qualcomm.com> On Monday 04 Mar 2024 at 15:37:41 (-0800), Elliot Berman wrote: > On Mon, Mar 04, 2024 at 01:10:48PM +0000, Quentin Perret wrote: > > On Friday 23 Feb 2024 at 16:37:23 (-0800), Elliot Berman wrote: > > > On Thu, Feb 22, 2024 at 11:09:40PM -0800, Christoph Hellwig wrote: > > > > On Thu, Feb 22, 2024 at 03:16:42PM -0800, Elliot Berman wrote: > > > > > Firmware and hypervisor drivers can donate system heap memory to their > > > > > respective firmware/hypervisor entities. Those drivers should unmap the > > > > > pages from the kernel's logical map before doing so. > > > > > > > > > > Export can_set_direct_map, set_direct_map_invalid_noflush, and > > > > > set_direct_map_default_noflush. > > > > > > > > Err, not they should not. And not using such super low-level interfaces > > > > from modular code. > > > > > > Hi Cristoph, > > > > > > We've observed a few times that Linux can unintentionally access a page > > > we've unmapped from host's stage 2 page table via an unaligned load from > > > an adjacent page. The stage 2 is managed by Gunyah. There are few > > > scenarios where even though we allocate and own a page from buddy, > > > someone else could try to access the page without going through the > > > hypervisor driver. One such instance we know about is > > > load_unaligned_zeropad() via pathlookup_at() [1]. > > > > > > load_unaligned_zeropad() could be called near the end of a page. If the > > > next page isn't mapped by the kernel in the stage one page tables, then > > > the access from to the unmapped page from load_unaligned_zeropad() will > > > land in __do_kernel_fault(), call fixup_exception(), and fill the > > > remainder of the load with zeroes. If the page in question is mapped in > > > stage 1 but was unmapped from stage 2, then the access lands back in > > > Linux in do_sea(), leading to a panic(). > > > > > > Our preference would be to add fixup_exception() to S2 PTW errors for > > > two reasons: > > > 1. It's cheaper to do performance wise: we've already manipulated S2 > > > page table and prevent intentional access to the page because > > > pKVM/Gunyah drivers know that access to the page has been lost. > > > 2. Page-granular S1 mappings only happen on arm64 with rodata=full. > > > > > > In an off-list discussion with the Android pkvm folks, their preference > > > was to have the pages unmapped from stage 1. I've gone with that > > > approach to get started but welcome discussion on the best approach. > > > > > > The Android (downstream) implementation of arm64 pkvm is currently > > > implementing a hack where s2 ptw faults are given back to the host as s1 > > > ptw faults (i.e. __do_kernel_fault() gets called and not do_sea()) -- > > > allowing the kernel to fixup the exception. > > > > > > arm64 pKVM will also face this issue when implementing guest_memfd or > > > when donating more memory to the hyp for s2 page tables, etc. As far as > > > I can tell, this isn't an issue for arm64 pKVM today because memory > > > isn't being dynamically donated to the hypervisor. > > > > FWIW pKVM already donates memory dynamically to the hypervisor, to store > > e.g. guest VM metadata and page-tables, and we've never seen that > > problem as far as I can recall. > > > > A key difference is that pKVM injects a data abort back into the kernel > > in case of a stage-2 fault, so the whole EXTABLE trick/hack in > > load_unaligned_zeropad() should work fine out of the box. > > > > As discussed offline, Gunyah injecting an SEA into the kernel is > > questionable, but I understand that the architecture is a bit lacking in > > this department, and that's probably the next best thing. > > > > Could the Gunyah driver allocate from a CMA region instead? That would > > surely simplify unmapping from EL1 stage-1 (similar to how drivers > > usually donate memory to TZ). > > In my opinion, CMA is overly restrictive because we'd have to define the > region up front and we don't know how much memory the virtual machines > the user will want to launch. I was thinking of using CMA to allocate pages needed to store guest metadata and such at EL2, but not to back the actual guest pages themselves. That still means overallocating somehow, but that should hopefully be much smaller and be less of a problem? For the actual guest pages, the gunyah variant of guestmem will have to unmap the pages from the direct map itself, but I'd be personally happy with making that part non-modular to avoid the issue Christoph and others have raised. Thanks, Quentin 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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id E2133C54798 for ; Tue, 5 Mar 2024 15:31:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type: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:Cc:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=iO1TNZBn02+P8gka6rHHqie45s9KcPDmYzkhZKhUAGM=; b=jL/vK4iN6tLATc RZNuMrEIt+s4dtBjhxtBHmIU3ovtxF93c7JPlv3NsVxFR9zfiYV0K5CYI+8UzAqwbvly9UX3KBSZ2 iwDUBMTxBHhBNE7vJHyPHVKcKDC0DCLm6/rFiYyyENb3OBtNOk3lq07JwWAx1zVUHpLGVHapEkVCS XGhc5j31HCtT3T4M0wp+my4a5Z+jfQNYB8B9Re1x97Ud2KSxPBEtwkwArgsYrBPbf/D/yBMmMxDUB CASP+Qxw4j5GItA985lVLPy5qJ2YOpiizRd1OJhX1aqhLOF7X2jRI+4KgS5woeN3qJ/br1Ifp4tHS pi8ReFw6pDAwskDbqG9Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rhWl8-0000000EHB3-2lx1; Tue, 05 Mar 2024 15:31:14 +0000 Received: from mail-ej1-x631.google.com ([2a00:1450:4864:20::631]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rhWl3-0000000EH8W-2xTZ for linux-arm-kernel@lists.infradead.org; Tue, 05 Mar 2024 15:31:13 +0000 Received: by mail-ej1-x631.google.com with SMTP id a640c23a62f3a-a4467d570cdso597825466b.3 for ; Tue, 05 Mar 2024 07:31:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1709652663; x=1710257463; darn=lists.infradead.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=jFBfmrcURu1fWMu57pWuFBzvegWbvE+xd+YhP2c5sxY=; b=d0+ALxO0up0lzbxbc7YzIkMGscikKoxmBAMsnwwUeloKvHT48n/9PojxuTGGZPfgwO U2qDUdiv8W7zxjfR5om7FgEToucUGLeDg7BTeOZ4uhFhoCOmLgIeFhPSx/KHfQCRXtQw wNQcc3rO+k180lG1TCDXkq758SRQY78HniTX9JByfd5cHq4am0OQfwB4FroTkq4xuuq5 TU9MPHzgKOhzcligwGMZntdZejGEz4R0ALbnDOtDjt3ar/0/QBOXHAvo2Gfzwj4wvjpt 2UCahPPzxoZPQlLUdA4XBZSAZYLZozUZDfHrFmfn2e4IOUysNd4//q8xYlGus0wHa0DT JvFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709652663; x=1710257463; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=jFBfmrcURu1fWMu57pWuFBzvegWbvE+xd+YhP2c5sxY=; b=dVS+m2keovSbRsthcQ38RnEQ5KNiht2vz4kPCnXE5qtPYiS+3Uxv7iVJTLQjR9jjQl VUNuSKHPX4S+sTpNDc0PBU9hNAYhzExhGHpzRbLg0IlAGJqUYPDeuuoxJxQHnGLlPjuM mYvUmgge+kVfSTim7IKlVncMNuHG5Lq1OcUxAseaxgU95Rhsg/DAwMI77dhHoeYqVjy2 E87rTMyE80Atcu7K5iNIzpZ3XGZFxaUhlhBCW1eyQNkOYr/nHG0/X3/IRuTyo4IXTXx6 VXjzpGrxXomR7YiVWPFcpjv7NbsvRDXR+4amOq4AilpNapKMzIkYs/OqRXc3QGHIx+Um eMqw== X-Forwarded-Encrypted: i=1; AJvYcCU4/Z/N7vMVkwtT4rcbLIhNnxOsxNWUXXX3IXzKXVGBGj9J2pv9ZlbpPGLIWIDs5jPw832+/iMFMrIxnGs3mK5sE+ymqPccrLSOe91ebu3Pkph+Wpo= X-Gm-Message-State: AOJu0Yw7mcIvTil9q4dc4e7D7CLzlmOVKcUNJkwW6P0msfVaHD5DAcc3 4W539c1Na1HvREDXTkAfjpWu6zdo98e+m8XSKhLRv3ZtWbAFLWvp2N22j6mdfQ== X-Google-Smtp-Source: AGHT+IG865qowYD6hypu+joiq3mkfJptCDN2wk6XWC4gZD4eKgj4/V+czQN2m8CgWrMksvV0eTX+4A== X-Received: by 2002:a17:906:4148:b0:a44:f89:a04e with SMTP id l8-20020a170906414800b00a440f89a04emr9475926ejk.35.1709652663164; Tue, 05 Mar 2024 07:31:03 -0800 (PST) Received: from google.com (64.227.90.34.bc.googleusercontent.com. [34.90.227.64]) by smtp.gmail.com with ESMTPSA id bw16-20020a170906c1d000b00a3fb9f1f10csm6146724ejb.161.2024.03.05.07.31.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Mar 2024 07:31:02 -0800 (PST) Date: Tue, 5 Mar 2024 15:30:58 +0000 From: Quentin Perret To: Christoph Hellwig , Will Deacon , Chris Goldsworthy , Android KVM , Patrick Daly , Alex Elder , Srinivas Kandagatla , Murali Nalajal , Trilok Soni , Srivatsa Vaddagiri , Carl van Schaik , Philip Derrin , Prakruthi Deepak Heragu , Jonathan Corbet , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Catalin Marinas , Konrad Dybcio , Bjorn Andersson , Dmitry Baryshkov , Fuad Tabba , Sean Christopherson , Andrew Morton , linux-arm-msm@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org Subject: Re: Re: Re: [PATCH v17 19/35] arch/mm: Export direct {un,}map functions Message-ID: References: <20240222-gunyah-v17-0-1e9da6763d38@quicinc.com> <20240222-gunyah-v17-19-1e9da6763d38@quicinc.com> <20240223071006483-0800.eberman@hu-eberman-lv.qualcomm.com> <20240304094828133-0800.eberman@hu-eberman-lv.qualcomm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20240304094828133-0800.eberman@hu-eberman-lv.qualcomm.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240305_073109_803087_056B0C08 X-CRM114-Status: GOOD ( 45.23 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 Monday 04 Mar 2024 at 15:37:41 (-0800), Elliot Berman wrote: > On Mon, Mar 04, 2024 at 01:10:48PM +0000, Quentin Perret wrote: > > On Friday 23 Feb 2024 at 16:37:23 (-0800), Elliot Berman wrote: > > > On Thu, Feb 22, 2024 at 11:09:40PM -0800, Christoph Hellwig wrote: > > > > On Thu, Feb 22, 2024 at 03:16:42PM -0800, Elliot Berman wrote: > > > > > Firmware and hypervisor drivers can donate system heap memory to their > > > > > respective firmware/hypervisor entities. Those drivers should unmap the > > > > > pages from the kernel's logical map before doing so. > > > > > > > > > > Export can_set_direct_map, set_direct_map_invalid_noflush, and > > > > > set_direct_map_default_noflush. > > > > > > > > Err, not they should not. And not using such super low-level interfaces > > > > from modular code. > > > > > > Hi Cristoph, > > > > > > We've observed a few times that Linux can unintentionally access a page > > > we've unmapped from host's stage 2 page table via an unaligned load from > > > an adjacent page. The stage 2 is managed by Gunyah. There are few > > > scenarios where even though we allocate and own a page from buddy, > > > someone else could try to access the page without going through the > > > hypervisor driver. One such instance we know about is > > > load_unaligned_zeropad() via pathlookup_at() [1]. > > > > > > load_unaligned_zeropad() could be called near the end of a page. If the > > > next page isn't mapped by the kernel in the stage one page tables, then > > > the access from to the unmapped page from load_unaligned_zeropad() will > > > land in __do_kernel_fault(), call fixup_exception(), and fill the > > > remainder of the load with zeroes. If the page in question is mapped in > > > stage 1 but was unmapped from stage 2, then the access lands back in > > > Linux in do_sea(), leading to a panic(). > > > > > > Our preference would be to add fixup_exception() to S2 PTW errors for > > > two reasons: > > > 1. It's cheaper to do performance wise: we've already manipulated S2 > > > page table and prevent intentional access to the page because > > > pKVM/Gunyah drivers know that access to the page has been lost. > > > 2. Page-granular S1 mappings only happen on arm64 with rodata=full. > > > > > > In an off-list discussion with the Android pkvm folks, their preference > > > was to have the pages unmapped from stage 1. I've gone with that > > > approach to get started but welcome discussion on the best approach. > > > > > > The Android (downstream) implementation of arm64 pkvm is currently > > > implementing a hack where s2 ptw faults are given back to the host as s1 > > > ptw faults (i.e. __do_kernel_fault() gets called and not do_sea()) -- > > > allowing the kernel to fixup the exception. > > > > > > arm64 pKVM will also face this issue when implementing guest_memfd or > > > when donating more memory to the hyp for s2 page tables, etc. As far as > > > I can tell, this isn't an issue for arm64 pKVM today because memory > > > isn't being dynamically donated to the hypervisor. > > > > FWIW pKVM already donates memory dynamically to the hypervisor, to store > > e.g. guest VM metadata and page-tables, and we've never seen that > > problem as far as I can recall. > > > > A key difference is that pKVM injects a data abort back into the kernel > > in case of a stage-2 fault, so the whole EXTABLE trick/hack in > > load_unaligned_zeropad() should work fine out of the box. > > > > As discussed offline, Gunyah injecting an SEA into the kernel is > > questionable, but I understand that the architecture is a bit lacking in > > this department, and that's probably the next best thing. > > > > Could the Gunyah driver allocate from a CMA region instead? That would > > surely simplify unmapping from EL1 stage-1 (similar to how drivers > > usually donate memory to TZ). > > In my opinion, CMA is overly restrictive because we'd have to define the > region up front and we don't know how much memory the virtual machines > the user will want to launch. I was thinking of using CMA to allocate pages needed to store guest metadata and such at EL2, but not to back the actual guest pages themselves. That still means overallocating somehow, but that should hopefully be much smaller and be less of a problem? For the actual guest pages, the gunyah variant of guestmem will have to unmap the pages from the direct map itself, but I'd be personally happy with making that part non-modular to avoid the issue Christoph and others have raised. Thanks, Quentin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel