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 38B9BC27C53 for ; Sat, 22 Jun 2024 18:57:34 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sL5uo-00075T-FK; Sat, 22 Jun 2024 14:56:46 -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 1sL5um-00074S-JY for qemu-devel@nongnu.org; Sat, 22 Jun 2024 14:56:44 -0400 Received: from mail-pj1-x102e.google.com ([2607:f8b0:4864:20::102e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sL5uk-0001CV-LV for qemu-devel@nongnu.org; Sat, 22 Jun 2024 14:56:44 -0400 Received: by mail-pj1-x102e.google.com with SMTP id 98e67ed59e1d1-2c8062f9097so1900247a91.3 for ; Sat, 22 Jun 2024 11:56:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1719082600; x=1719687400; darn=nongnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=MMIqqK8EHLIK636ZVfBV7/GjmZU89gW9RKNOtKYIEt4=; b=JIMzVpHhO7ITdKRerGDqn02Z+jrqGSeoi7tqdc4mJo1Fara9Y8vW2iiMW/TJ/JnUIX 29s+HgvXlHc4bhgOHuuq6sfqqcWWl9gKdSil2IjNiVuBx+H4mANxYrgdsga1XVMg/y82 SRxNgcdwsBbkX5eE/pwWob+/A9NfQ3hl7sIpRVlY8Ckt7QRfQmQezT/v7+6R65Jl9VBB nsUm2Np38MZEHaSK0uFWuE15hwe3UAcOCcyugw3afsg5Qx5/Q7SsVvPU2Qv3oGaC74cu MXuR3AXGX5U8otDSq5xzUWG1MO2UhNUKDiVr1gqrXeyrjxV1c4leniCN6xj1xp4yiCKN WIrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719082600; x=1719687400; 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=MMIqqK8EHLIK636ZVfBV7/GjmZU89gW9RKNOtKYIEt4=; b=DJ/qC48HdleMt8z2UpJk8x4qGh6Cdj+MEHdyDXVK4/sKAs+aZsc5k08qbV/XRE1RO6 U/WmSuMByQb+YVREiTa7Tu19AIGkkWl6OE9rnKaR1uebLClM2SJ9vIqDgCm0zaXHkVQ7 VJpqSxY2w7Kt0aO3LQqmErCY7pOrgQinjKIj2B1eek0gE5grILuirzw6Wlc3Nqj7CkrV oFYNh5GhmwOgG0f6NbLN7vZCr3cwZtzYgAQdJFGd//jSKILcAEHkc8RKyoA5DhvaUFlI +5GOuBQmvQCnGLtn3liLfAfUZx8lGym5PBFW6dIZyfy5yXcHgssgktYg7Cmi+1IYzmfC 65Kw== X-Forwarded-Encrypted: i=1; AJvYcCVg4KDVzUwCYiTTv/6YnRT5SWZI6OO29GMeeFCk1JvslhQoZrPn6tIO0oWw5vm32N+c5AXEjGCEJElD6QEpkqcZvSJSG0E= X-Gm-Message-State: AOJu0Yxbvuxus/ONCs+eMDdBG3ACPp2YvBUq+mClbDxouSC/QcjMxI7w Waci/gvoswo6kiLfz+xHzEbYFJzcub+LCFUzYfUWi/AR6p6r8sc3QSPdm1Uvy5MEdIeXwjGOFlc NWub9KYX6MkCVd3VhAxRlThnvlWP1LDff/tD2aw== X-Google-Smtp-Source: AGHT+IEQES5K0QJbYbWhViK6MccqD9tWphEdeVJh0OIHNisVGNnrWseuVr3J8SQfI9M8/13vQEHPjxXhMNqHf5L5k9I= X-Received: by 2002:a17:902:ce89:b0:1f7:d1d:21ea with SMTP id d9443c01a7336-1fa23edac05mr6052575ad.32.1719082600563; Sat, 22 Jun 2024 11:56:40 -0700 (PDT) MIME-Version: 1.0 References: <20240617185804.25075-1-itachis@FreeBSD.org> <20240617185804.25075-12-itachis@FreeBSD.org> In-Reply-To: From: Warner Losh Date: Sat, 22 Jun 2024 12:56:29 -0600 Message-ID: Subject: Re: [PATCH 11/23] Update ARM AArch64 VM parameter definitions for bsd-user To: Richard Henderson Cc: Ajeet Singh , qemu-devel@nongnu.org, Ajeet Singh , Stacey Son , Sean Bruno Content-Type: multipart/alternative; boundary="000000000000bf2ed4061b7f1b2c" Received-SPF: none client-ip=2607:f8b0:4864:20::102e; envelope-from=wlosh@bsdimp.com; helo=mail-pj1-x102e.google.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001 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 --000000000000bf2ed4061b7f1b2c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jun 18, 2024 at 4:16=E2=80=AFPM Richard Henderson < richard.henderson@linaro.org> wrote: > On 6/17/24 11:57, Ajeet Singh wrote: > > From: Stacey Son > > > > Defined address spaces for FreeBSD/arm64 and added function for > > getting stack pointer from CPU and setting a return value. > > > > Signed-off-by: Stacey Son > > Signed-off-by: Warner Losh > > Signed-off-by: Ajeet Singh > > Co-authored-by: Sean Bruno > > Co-authored-by: Warner Losh > > --- > > bsd-user/aarch64/target_arch_vmparam.h | 68 +++++++++++++++++++++++++= + > > 1 file changed, 68 insertions(+) > > create mode 100644 bsd-user/aarch64/target_arch_vmparam.h > > Acked-by: Richard Henderson > > > + /* KERNBASE - 512 MB */ > > +#define TARGET_VM_MAXUSER_ADDRESS (0x00007fffff000000ULL - (512 * > MiB)) > > +#define TARGET_USRSTACK TARGET_VM_MAXUSER_ADDRESS > > I will note that this may conflict with -R reserved_size, > and is an existing issue with the x86_64 port as well. > There are indeed existing issues with address space management. We're working through them right now in the blitz branch. We have finally found where the atomic issues were coming from and it is not setting the flag saying we want atomic ops when creating the CPU structures (that's a quick summary, I'll post more on this later when we review it). So I'd suggest, for the moment, allowing this in and fixing it when we get those details ironed out. Does that sound OK? Warner --000000000000bf2ed4061b7f1b2c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jun 18, 2024 at 4:16=E2=80=AF= PM Richard Henderson <ri= chard.henderson@linaro.org> wrote:
On 6/17/24 11:57, Ajeet Singh wrote:
> From: Stacey Son <sson@FreeBSD.org>
>
> Defined address spaces for FreeBSD/arm64 and added function for
> getting stack pointer from CPU and setting a return value.
>
> Signed-off-by: Stacey Son <sson@FreeBSD.org>
> Signed-off-by: Warner Losh <imp@bsdimp.com>
> Signed-off-by: Ajeet Singh <itachis@FreeBSD.org>
> Co-authored-by: Sean Bruno <sbruno@freebsd.org>
> Co-authored-by: Warner Losh <imp@bsdimp.com>
> ---
>=C2=A0 =C2=A0bsd-user/aarch64/target_arch_vmparam.h | 68 ++++++++++++++= ++++++++++++
>=C2=A0 =C2=A01 file changed, 68 insertions(+)
>=C2=A0 =C2=A0create mode 100644 bsd-user/aarch64/target_arch_vmparam.h<= br>
Acked-by: Richard Henderson <richard.henderson@linaro.org>

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* KERNBASE -= 512 MB */
> +#define TARGET_VM_MAXUSER_ADDRESS=C2=A0 =C2=A0(0x00007fffff000000ULL = - (512 * MiB))
> +#define TARGET_USRSTACK=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0TARGET_VM_MAXUSER_ADDRESS

I will note that this may conflict with -R reserved_size,
and is an existing issue with the x86_64 port as well.

There are indeed existing issues with address space managem= ent. We're working through
them right now in the blitz branch= . We have finally found where the atomic issues were
coming from = and it is <blush> not setting the flag saying we want atomic ops when= creating
the CPU structures (that's a quick summary, I'l= l post more on this later when we review it).
So I'd suggest,= for the moment, allowing this in and fixing it when we get those details
ironed out. Does that sound OK?

Warner
--000000000000bf2ed4061b7f1b2c--