Aleksandar Markovic <aleksandar.qemu.de...@gmail.com> writes:
> сре, 27. мај 2020. у 14:05 Aleksandar Markovic > <aleksandar.qemu.de...@gmail.com> је написао/ла: >> >> сре, 27. мај 2020. у 12:07 Alex Bennée <alex.ben...@linaro.org> је >> написао/ла: >> > >> > We rely on the pointer to wrap when accessing the high address of the >> > COMMPAGE so it lands somewhere reasonable. However on 32 bit hosts we >> > cannot afford just to map the entire 4gb address range. The old mmap >> > trial and error code handled this by just checking we could map both >> > the guest_base and the computed COMMPAGE address. >> > >> > We can't just manipulate loadaddr to get what we want so we introduce >> > an offset which pgb_find_hole can apply when looking for a gap for >> > guest_base that ensures there is space left to map the COMMPAGE >> > afterwards. >> > >> > This is arguably a little inefficient for the one 32 bit >> > value (kuser_helper_version) we need to keep there given all the >> > actual code entries are picked up during the translation phase. >> > >> > Fixes: ee94743034b >> > Bug: https://bugs.launchpad.net/qemu/+bug/1880225 >> >> For the scenario in this bug report, for today's master, before and after >> applying this patch: >> > > I am not sure how significant is this info, but I executed the test > without applying patch 1/3, so only 2/3 was applied in the case > "AFTER". That is expected. The other fix only affects binaries run inside a /proc-less chroot and the final patch is a test case for COMMPAGE support. -- Alex Bennée
