Paolo Bonzini <pbonz...@redhat.com> writes: > On 07/03/2016 20:25, Markus Armbruster wrote: >> gethugepagesize() works reliably only when its argument is on >> hugetlbfs. When it's not, it returns the filesystem's "optimal >> transfer block size", which may or may not be the actual page size >> you'll get when you mmap(). >> >> If the value is too small or not a power of two, we fail >> qemu_ram_mmap()'s assertions. These were added in commit 794e8f3 >> (v2.5.0). The bug's impact before that is currently unknown. Seems >> fairly unlikely at least when the normal page size is 4KiB. >> >> Else, if the value is too large, we align more strictly than >> necessary. >> >> gethugepagesize() goes back to commit c902760 (v0.13). That commit >> clearly intended gethugepagesize() to be used on hugetlbfs only. Not >> only was it named accordingly, it also printed a warning when used on >> anything else. However, the commit neglected to spell out the >> restriction in user documentation of -mem-path. >> >> Commit bfc2a1a (v2.5.0) dropped the warning as bogus "because QEMU >> functions perfectly well with the path on a regular tmpfs filesystem". >> It sure does when you're sufficiently lucky. In my testing, I was >> lucky, too. >> >> Fix by switching to qemu_fd_getpagesize(). Rename the variable >> holding its result from hpagesize to page_size. >> >> Cc: Paolo Bonzini <pbonz...@redhat.com> >> Signed-off-by: Markus Armbruster <arm...@redhat.com> [...] > > Queued, thanks.
Not in master, yet. What repo+branch should I use as base for v3?
