On Tue, Sep 4, 2018 at 3:10 PM, Peter Maydell <peter.mayd...@linaro.org> wrote: > On 4 September 2018 at 23:02, Max Filippov <jcmvb...@gmail.com> wrote: >> On Tue, Sep 4, 2018 at 2:13 PM, Peter Maydell <peter.mayd...@linaro.org> >> 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 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. > > I'm not sure why you think that we should treat 32-on-64 differently.
I'm not sure, it's just that I have a case that I'd like to fix, and it's 32-on 64. > 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 internal > allocation as a guest one, so not to imposing the limit at all > would avoid QEMU failing then. But that would apply in both the > 32-on-64 and also 32-on-32 and 64-on-64 cases too. That's what I did initially, but it feels somewhat unsafe in 64-on-64 case. My expectation is that limits set by 64-bit guest should be somewhat suitable for the 64-bit host, is it wrong? -- Thanks. -- Max
