qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Richard Henderson
Subject: Re: [PATCH 6/9] bsd-user: common routine do_freebsd_sysctl_oid for all sysctl variants
Date: Sat, 11 Feb 2023 13:59:50 -1000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1

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 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.


r~



reply via email to

[Prev in Thread] Current Thread [Next in Thread]