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