Re: [PATCH 6/9] bsd-user: common routine do_freebsd_sysctl_oid for all sysctl variants

[Warner Losh <imp@bsdimp.com>]

[-- Attachment #1: Type: text/plain, Size: 2512 bytes --]

On Sat, Feb 11, 2023 at 4:59 PM Richard Henderson <
richard.henderson@linaro.org> wrote:

> On 2/11/23 13:40, Warner Losh wrote:
> > maxmem is defined earlier in this patch:
> >
> > +#if TARGET_ABI_BITS != HOST_LONG_BITS
> > +    const abi_ulong maxmem = -0x100c000;
> >
> > but I'm not at all sure how that number was arrived at...
> > It's a little less than ULONG_MAX is all I can say for
> > sure.
> >
> > As to why it's a special case only sometimes, I believe that it's there
> for 32-bit
> > targets running on 64-bit hosts so that we return a sane amount of
> memory because
> > 64-bit hosts can have > 4GB of ram... I'm not 100% sure of this, and it
> would
> > likely be wrong for 32-bit host and 64-bit target, but that case isn't
> supported at
> > all by the bsd-user project (though in the past it may have been, we no
> longer
> > built even 32 on 32 target/host emulation).
>
> Perhaps you're looking for reserved_va?  I.e. the max va the guest is
> limited to?
>
> Or, given this is a system-wide number of pages, not per-process, and
> given the types
> involved, cap at UINT32_MAX?
>

I think that I'll use UINT32_MAX - <magic number> + 1 here. I'll explain
that <magic number>
was empirically determined. I'm looking at all repos to see if there's a
better explanation there.


> >     I would expect a 64-bit guest to rescale the result for
> TARGET_PAGE_SIZE != getpagesize().
> >
> >
> > I would too. I suspect that the reason this is here like this is that an
> attempt
> > was being made to handle it, but since TARGET_PAGE_SIZE == getpagesize()
> on
> > all hosts / target pairs until very recently (with the 16k arm64
> kernels), this was
> > a latent bug in the code and I should fix it before my next submission.
> And aarch64
> > hosts for this are quite rare (most people use bsd-user on amd64 hosts
> to build for
> > all the other architectures).
>
> Ok.  When you do this, remember muldiv64.
>

I was going to do something like:

+    if (host_page_size != TARGET_PAGE_SIZE) {
+        if (host_page_size > TARGET_PAGE_SIZE) {
+            /* Scale up */
+            pages *= host_page_size / TARGET_PAGE_SIZE;
+        } else {
+            /* Scale down with truncation */
+            pages /= TARGET_PAGE_SIZE / host_page_size;
+        }
+    }

in a helper function. Does multdiv64 replace that? It's currently unused in
both linux-user
and bsd-user. The above does things in a known-good order (or at least
that's my belief,
even after 30 years C surprises me).

Warner

[-- Attachment #2: Type: text/html, Size: 3406 bytes --]