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 lists.gnu.org (lists.gnu.org [209.51.188.17]) (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 B73D4EB64D9 for ; Thu, 15 Jun 2023 21:01:16 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q9u4y-0000vD-2a; Thu, 15 Jun 2023 17:00:28 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q9u4v-0000tb-IZ for qemu-devel@nongnu.org; Thu, 15 Jun 2023 17:00:26 -0400 Received: from mail-ed1-x52b.google.com ([2a00:1450:4864:20::52b]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1q9u4t-0004am-O9 for qemu-devel@nongnu.org; Thu, 15 Jun 2023 17:00:25 -0400 Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-519608ddbf7so2858110a12.2 for ; Thu, 15 Jun 2023 14:00:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1686862819; x=1689454819; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=WYLbYL1krmcSknFae1Ccf4OFvXtZnYlTokiPxqIQBcI=; b=mG3B9RpjKsDDcaelO6hZCWoXkT1Wx4RqMq50Rmo81sl2kBuamG1ocLzTF5cnMkMTkk TZ8DrG1Xba7uhfCri4tRGea8KUDyx0QXmxvf5XiDDRHsOWKky/VaNPqDtes/YA3JObJ2 0tDY8voWnAnsDBdlBVrobf/LT6M/CWR83t1qolddAwjANyTU1UATFNdtg430wBCq22zS zS2+Rz6fU4Ikd3PtT4mDg528euNrpe+SyQCNUTVkE+V+nORVN3kUD3r5jkw76mDTpxdY QoF752YaQA5vTBxWlj3Jggmj09VpNTsDScgb22I3ptZa40qqYMRjoOSx4LXd7toZWi2P nKAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686862819; x=1689454819; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=WYLbYL1krmcSknFae1Ccf4OFvXtZnYlTokiPxqIQBcI=; b=VJghTCWKfBo/WOmmV04ZmgtYFZeYqrFPPcM/RHsoOs4FnXF15vuIqQigdE4W/D6bAF obEb/7qRJa+uQ1GsOP1+AngPdTNbI5QtNFeuQxxHhP4Bb2TXki5VLS8zQxSgG0z0eS27 KGLvz+MS4t4WP2RPeX7S/+wROx3i2Ejm5wH+lrYwBI+qovqlghK+Fuz2Ee/4vqmYRTIe UoaVXHmMhdXgTA5IW3q4HYXig/fK3axPF6BtIeXy2PgtA0uUXlLq91sBCZyV5XCRANUD xav44aGZvUFgR7I8E6I0biW10zkG8Rat6BXqWqcRARnaJAS3xvzjLWvaRvNG2YfzcYdz Je/g== X-Gm-Message-State: AC+VfDwjJkY3k5CODVRfOkEaAIWZ0cOoNMaVuzgkuHQPK6QeWofZd3v0 RVksyax3EwDq4X1grCL9QlV2OL82M2aTO7BzRAtzZ3MiaIzAoA== X-Google-Smtp-Source: ACHHUZ6qwOkxRtEUCZp3d9K1JGCNs9XeSBMDckFoOd1ydIFmpgxVOiWY5Yjo4A9Uzzt5aHyfnzQHCLu4+ntNRUGRdKo= X-Received: by 2002:aa7:d38b:0:b0:51a:2caa:672c with SMTP id x11-20020aa7d38b000000b0051a2caa672cmr10823edq.30.1686862818927; Thu, 15 Jun 2023 14:00:18 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Mohd Yusuf Abdul Hamid Date: Thu, 15 Jun 2023 13:59:42 -0700 Message-ID: Subject: Re: QEMU virt (arm64) does not honor reserved-memory set in device tree To: Gavin Shan Cc: qemu-devel@nongnu.org Content-Type: multipart/alternative; boundary="0000000000001b687605fe315b99" Received-SPF: pass client-ip=2a00:1450:4864:20::52b; envelope-from=mohdyusuf@gmail.com; helo=mail-ed1-x52b.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org --0000000000001b687605fe315b99 Content-Type: text/plain; charset="UTF-8" Hi Gavin, Thanks for the reply. I am new to Linux dev in general and not familiar with the ACPI table, but I will research in the area and give it a try. Sorry for the late response. -Yusuf On Fri, Jun 9, 2023, 8:36 PM Gavin Shan wrote: > Hi Mohd, > > On 6/10/23 10:01 AM, Mohd Yusuf Abdul Hamid wrote: > > I am trying to reserve a portion of the system memory in QEMU (arm64 > virt), v7.2.1 - but the kernel never honors the reserved memory area and > keeps using the area. > > > > Say, I dumped out DTB and added: > > > > reserved-memory { > > #address-cells = <0x02>; > > #size-cells = <0x02>; > > > > rsvdram@50000000 { > > no-map; > > reg = <0x00 0x50000000 0x00 0x20000000>; > > }; > > }; > > > > When booted, /proc/iomem still shows the kernel is using the entire > space - eg 2GB. > > > > Is this a supported feature or I would need to modify the virt.c and > define scratch area for some device driver scratch area. > > > > It relies on the guest kernel to handle the device-tree and the > device-tree node > for the reserved map. I doubt if you had ACPI over device-tree in the > guest kernel's > configuration. In this case, the reserved memory regions need to be > specified in > ACPI tables instead of device-tree. > > Thanks, > Gavin > > --0000000000001b687605fe315b99 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Gavin,
Thanks for th= e reply. I am new to Linux dev in general and not familiar with the ACPI ta= ble, but I will research in the area and give it a try.

Sorry for the late response.

-Y= usuf

On Fri, Jun 9, 2023, 8:36 PM Gavin Shan <gshan@redhat.com> wrote:
<= /div>
Hi Mohd,

On 6/10/23 10:01 AM, Mohd Yusuf Abdul Hamid wrote:
> I am trying to reserve a portion of the system memory in QEMU (arm64 v= irt), v7.2.1 - but the kernel never honors the reserved memory area and kee= ps using the area.
>
> Say, I dumped out DTB and added:
>
> reserved-memory {
>=C2=A0 =C2=A0 #address-cells =3D <0x02>;
>=C2=A0 =C2=A0 #size-cells =3D <0x02>;
>
>=C2=A0 =C2=A0 rsvdram@50000000 {
>=C2=A0 =C2=A0 no-map;
>=C2=A0 =C2=A0 reg =3D <0x00 0x50000000 0x00 0x20000000>;
>=C2=A0 =C2=A0 };
> };
>
> When booted, /proc/iomem still shows the kernel is using the entire sp= ace - eg 2GB.
>
> Is this a supported feature or I would need to modify the virt.c and d= efine scratch area for some device driver scratch area.
>

It relies on the guest kernel to handle the device-tree and the device-tree= node
for the reserved map. I doubt if you had ACPI over device-tree in the guest= kernel's
configuration. In this case, the reserved memory regions need to be specifi= ed in
ACPI tables instead of device-tree.

Thanks,
Gavin

--0000000000001b687605fe315b99--