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=-10.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 8FB11C4338F for ; Tue, 10 Aug 2021 22:40:00 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id D314C60EBD for ; Tue, 10 Aug 2021 22:39:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org D314C60EBD Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=bsdimp.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=nongnu.org Received: from localhost ([::1]:34758 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mDaPe-0005MN-N8 for qemu-devel@archiver.kernel.org; Tue, 10 Aug 2021 18:39:58 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:37038) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mDaOh-0004f0-QZ for qemu-devel@nongnu.org; Tue, 10 Aug 2021 18:38:59 -0400 Received: from mail-qt1-x829.google.com ([2607:f8b0:4864:20::829]:39528) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mDaOg-00049v-2Z for qemu-devel@nongnu.org; Tue, 10 Aug 2021 18:38:59 -0400 Received: by mail-qt1-x829.google.com with SMTP id d2so469241qto.6 for ; Tue, 10 Aug 2021 15:38:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fPY2TLUHLAj38g221xWRfVifEnjOM4Uau3Qj/FVTnvM=; b=QuWwvQ8m4iK3iM42jy9wTlxUEYC9zA72XW+w1g6D+QmCf/t89cc9AN3of2P4Mt3OK4 em12u2oKtqBzik9SffPn031+Kpn4EhRt+KvmWn48kV0ROCyl48x+Ep38laYTaii2Qyzw UJSlhTMKkmFDGa66+i89Wzq1TdFQ3ci3XlpHpnF5ei+zVNp31lnWw8OqSFn7kGiKh9Rw DxzqbTaPTJMtu11orQ3O5cGuz4TvbsXYmyaBnJvSAXF0r4VyICX1oeFueZO3sGIM6WzS OYVQ0wUi5MCDSUdfj287jwA8eKoRC4rXNZuUtMZM5OIzGRQtayx9Nulga+/u9a0F6Ae4 hXJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fPY2TLUHLAj38g221xWRfVifEnjOM4Uau3Qj/FVTnvM=; b=Fb6UjBWxapgBsyPzuTNPN3xwHCQqVnHos9SrucGUvtS93t5ghX1gsJ3gantsWFpm50 ZC6JTjPKSAMczX8FBlyUG/zBj7vMCT0mo7cURi/fQWqY161pAaYo8QqiJJ3WmLo954a8 RlGVfseImr4hifJ/gkilmHPCM+s5rV6J68HRwFiu4qtl4p2dsitlMKNFgw1TZDr6NsbM pB4cTkMaWvrC1tTkOrOAZNBkIpMcey9qSI4MZXgON/RBB/17LXqzVWA9PnTFI0fI9/KS M71LuS52nks8mBr8+X3f+FICtReOswkJzjdHhUbBRgt3Ru3C5JXR0sdNDmfR/FZh6J9T e8wA== X-Gm-Message-State: AOAM532lt6L5lf9rKEtjmimMAxuh1ZsjzAOxZ5c9MES2ATZBjUfVyNeI nqltn/9elcpYqLwjmn5myVe3pFWoAHp0H0Ly9nLZ4A== X-Google-Smtp-Source: ABdhPJw/5R59WL6hS1U6RG1S9wEtBTqDSP2rNPp67MG2wDq2Uy91Vk3EbcZKrHfprvtZpfsdqaM8a1lld3b4zOhFCh8= X-Received: by 2002:ac8:6657:: with SMTP id j23mr15238281qtp.73.1628635137035; Tue, 10 Aug 2021 15:38:57 -0700 (PDT) MIME-Version: 1.0 References: <20210807214242.82385-1-imp@bsdimp.com> <20210807214242.82385-39-imp@bsdimp.com> In-Reply-To: From: Warner Losh Date: Tue, 10 Aug 2021 16:38:46 -0600 Message-ID: Subject: Re: [PATCH for 6.2 38/49] bsd-user: Update mapping to handle reserved and starting conditions To: Richard Henderson Content-Type: multipart/alternative; boundary="000000000000cfe34305c93c2a3b" Received-SPF: none client-ip=2607:f8b0:4864:20::829; envelope-from=wlosh@bsdimp.com; helo=mail-qt1-x829.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.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Kyle Evans , Warner Losh , QEMU Developers , =?UTF-8?Q?Mika=C3=ABl_Urankar?= , Stacey Son Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" --000000000000cfe34305c93c2a3b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Aug 10, 2021 at 10:27 AM Richard Henderson < richard.henderson@linaro.org> wrote: > On 8/7/21 11:42 AM, Warner Losh wrote: > > From: Warner Losh > > > > Update the reserved base based on what platform we're on, as well as th= e > > start of the mmap range. Update routines that find va ranges to interac= t > > with the reserved ranges as well as properly align the mapping (this is > > especially important for targets whose page size does not match the > > host's). Loop where appropriate when the initial address space offered > > by mmap does not meet the contraints. > > > > Signed-off-by: Mika=C3=ABl Urankar > > Signed-off-by: Stacey Son > > Signed-off-by: Warner Losh > > --- > > bsd-user/main.c | 23 ++- > > bsd-user/mmap.c | 372 ++++++++++++++++++++++++++++++++++++++++-------= - > > bsd-user/qemu.h | 5 +- > > 3 files changed, 335 insertions(+), 65 deletions(-) > > > > diff --git a/bsd-user/main.c b/bsd-user/main.c > > index 93ef9298b8..36852604f8 100644 > > --- a/bsd-user/main.c > > +++ b/bsd-user/main.c > > @@ -49,12 +49,29 @@ > > #include "target_arch_cpu.h" > > > > int singlestep; > > -unsigned long mmap_min_addr; > > uintptr_t guest_base; > > static const char *cpu_model; > > static const char *cpu_type; > > bool have_guest_base; > > +#if (TARGET_LONG_BITS =3D=3D 32) && (HOST_LONG_BITS =3D=3D 64) > > +/* > > + * When running 32-on-64 we should make sure we can fit all of the > possible > > + * guest address space into a contiguous chunk of virtual host memory. > > + * > > + * This way we will never overlap with our own libraries or binaries o= r > stack > > + * or anything else that QEMU maps. > > + */ > > +# ifdef TARGET_MIPS > > +/* MIPS only supports 31 bits of virtual address space for user space = */ > > +unsigned long reserved_va =3D 0x77000000; > > +# elif defined(TARGET_PPC64) > > +unsigned long reserved_va =3D 0xfffff000; > > +# else > > +unsigned long reserved_va =3D 0xf7000000; > > +# endif > > +#else > > unsigned long reserved_va; > > +#endif > > All of these 7's look to be copying an old linux-user bug. > I cleaned this up in 18e80c55bb6. > Oh nice. I'd missed that one... a bit before I started hacking on bsd-user, but quite nice indeed. > Otherwise, > Acked-by: Richard Henderson > > I would hope one day this memory management could be shared between the > user-only > implementations. It's complicated enough... > Honestly, one reason I want to get "caught up" with upstream is for such a refactor. There's so much duplication that it's hard to keep up. Warner --000000000000cfe34305c93c2a3b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Aug 10, 2021 at 10:27 AM Rich= ard Henderson <richard.h= enderson@linaro.org> wrote:
On 8/7/21 11:42 AM, Warner Losh wrote:
> From: Warner Losh <imp@FreeBSD.org>
>
> Update the reserved base based on what platform we're on, as well = as the
> start of the mmap range. Update routines that find va ranges to intera= ct
> with the reserved ranges as well as properly align the mapping (this i= s
> especially important for targets whose page size does not match the > host's). Loop where appropriate when the initial address space off= ered
> by mmap does not meet the contraints.
>
> Signed-off-by: Mika=C3=ABl Urankar <mikael.urankar@gmail.com>
> Signed-off-by: Stacey Son <sson@FreeBSD.org>
> Signed-off-by: Warner Losh <imp@bsdimp.com>
> ---
>=C2=A0 =C2=A0bsd-user/main.c |=C2=A0 23 ++-
>=C2=A0 =C2=A0bsd-user/mmap.c | 372 ++++++++++++++++++++++++++++++++++++= ++++--------
>=C2=A0 =C2=A0bsd-user/qemu.h |=C2=A0 =C2=A05 +-
>=C2=A0 =C2=A03 files changed, 335 insertions(+), 65 deletions(-)
>
> diff --git a/bsd-user/main.c b/bsd-user/main.c
> index 93ef9298b8..36852604f8 100644
> --- a/bsd-user/main.c
> +++ b/bsd-user/main.c
> @@ -49,12 +49,29 @@
>=C2=A0 =C2=A0#include "target_arch_cpu.h"
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0int singlestep;
> -unsigned long mmap_min_addr;
>=C2=A0 =C2=A0uintptr_t guest_base;
>=C2=A0 =C2=A0static const char *cpu_model;
>=C2=A0 =C2=A0static const char *cpu_type;
>=C2=A0 =C2=A0bool have_guest_base;
> +#if (TARGET_LONG_BITS =3D=3D 32) && (HOST_LONG_BITS =3D=3D 64= )
> +/*
> + * When running 32-on-64 we should make sure we can fit all of the po= ssible
> + * guest address space into a contiguous chunk of virtual host memory= .
> + *
> + * This way we will never overlap with our own libraries or binaries = or stack
> + * or anything else that QEMU maps.
> + */
> +# ifdef TARGET_MIPS
> +/* MIPS only supports 31 bits of virtual address space for user space= */
> +unsigned long reserved_va =3D 0x77000000;
> +# elif defined(TARGET_PPC64)
> +unsigned long reserved_va =3D 0xfffff000;
> +# else
> +unsigned long reserved_va =3D 0xf7000000;
> +# endif
> +#else
>=C2=A0 =C2=A0unsigned long reserved_va;
> +#endif

All of these 7's look to be copying an old linux-user bug.
I cleaned this up in 18e80c55bb6.

Oh ni= ce. I'd missed that one... a bit before I started hacking on bsd-user,<= /div>
but quite nice indeed.
=C2=A0
Otherwise,
Acked-by: Richard Henderson <richard.henderson@linaro.org>

I would hope one day this memory management could be shared between the use= r-only
implementations.=C2=A0 It's complicated enough...
=
Honestly, one reason I want to get "caught up" wit= h upstream is for such a refactor. There's
so much duplicatio= n that it's hard to keep up.

Warner
--000000000000cfe34305c93c2a3b--