On Tue, Sep 4, 2018 at 2:13 PM, Peter Maydell <peter.mayd...@linaro.org> wrote:
> On 4 September 2018 at 22:00, Max Filippov <jcmvb...@gmail.com> wrote:
>> When running 32-bit guest on 64-bit host setrlimit guest calls that
>> affect memory resources (RLIMIT_{AS,DATA,STACK}) don't always make sense
>> as is. They may result in QEMU lockup because mprotect call in
>> page_unprotect would fail with ENOMEM error code, causing infinite loop
>> of SIGSEGV. E.g. it happens when running libstdc++ testsuite for xtensa
>> target on x86_64 host.
>>
>> Don't call host setrlimit for memory-related resources when running
>> 32-bit guest on 64-bit host.
>
> I think the issue here is not related to 32-on-64 but to the fact
> that we just pass through the memory rlimits. What we should ideally
> be doing is tracking the actual guest memory allocations sufficiently
> that we can then apply the rlimits at the QEMU level, so that guest
> allocations that breach limits can be failed, without ever causing
> QEMU's own alloactions to fail.In a sense we do it by limiting 32-bit guest to 32 or less bits of the address space, that's why it should be rather safe to just ignore setrlimit calls in 32-on-64 case. -- Thanks. -- Max
