On Tue, Sep 4, 2018 at 6:40 PM, Peter Maydell wrote:
> I still think 32-on-64 is a red herring here. If ignoring
> client attempts to set the memory rlimits makes sense on
> 32-on-64 it makes sense for all configurations.
Ok, I don't have anything against ignoring guest setrlimit completely, so
On 5 September 2018 at 01:08, Max Filippov wrote:
> Ok, the deadlock (and other weird behavior) is a separate problem:
> QEMU doesn't check results of resource allocation functions and
> then gets surprised. Errors must be handled and QEMU must be
> terminated properly.
>
> As to hitting the
On Tue, Sep 4, 2018 at 3:55 PM, Peter Maydell wrote:
> On 4 September 2018 at 23:26, Max Filippov wrote:
>> On Tue, Sep 4, 2018 at 3:10 PM, Peter Maydell
>> wrote:
>>> On 4 September 2018 at 23:02, Max Filippov wrote:
>
>>> You could make a case for always ignoring setrlimit calls: if we
>>>
On 4 September 2018 at 23:26, Max Filippov wrote:
> On Tue, Sep 4, 2018 at 3:10 PM, Peter Maydell
> wrote:
>> On 4 September 2018 at 23:02, Max Filippov wrote:
>> You could make a case for always ignoring setrlimit calls: if we
>> ever hit the limit it's as likely to be by failing a QEMU
On Tue, Sep 4, 2018 at 3:10 PM, Peter Maydell wrote:
> On 4 September 2018 at 23:02, Max Filippov wrote:
>> On Tue, Sep 4, 2018 at 2:13 PM, Peter Maydell
>> wrote:
>>> 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
On 4 September 2018 at 23:02, Max Filippov wrote:
> On Tue, Sep 4, 2018 at 2:13 PM, Peter Maydell
> wrote:
>> 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
On Tue, Sep 4, 2018 at 2:13 PM, Peter Maydell wrote:
> On 4 September 2018 at 22:00, Max Filippov 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
On 4 September 2018 at 22:00, Max Filippov 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
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
