From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matt Evans Subject: Re: [PATCH V2 17/23] kvm tools: Add ability to map guest RAM from hugetlbfs Date: Mon, 12 Dec 2011 17:19:43 +1100 Message-ID: <4EE59CFF.5080304@ozlabs.org> References: <4EE1B0DD.6030004@ozlabs.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, kvm-ppc@vger.kernel.org, asias.hejun@gmail.com, levinsasha928@gmail.com, Cyrill Gorcunov , Ingo Molnar To: Pekka Enberg Return-path: In-Reply-To: Sender: kvm-ppc-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 09/12/11 19:38, Pekka Enberg wrote: > On Fri, Dec 9, 2011 at 8:55 AM, Matt Evans wrote: >> Add a --hugetlbfs commandline option to give a path to hugetlbfs-map guest >> memory (down in kvm__arch_init()). For x86, guest memory is a normal >> ANON mmap() if this option is not provided, otherwise a hugetlbfs mmap. >> >> Signed-off-by: Matt Evans > >> +void *mmap_hugetlbfs(const char *htlbfs_path, u64 size) >> +{ >> + char mpath[PATH_MAX]; >> + int fd; >> + int r; >> + struct statfs sfs; >> + void *addr; >> + >> + do { >> + /* >> + * QEMU seems to work around this returning EINTR... Let's do >> + * that too. >> + */ >> + r = statfs(htlbfs_path, &sfs); >> + } while (r && errno == EINTR); > > Can this really happen? What about EAGAIN? The retry logic really > wants to live in tools/kvm/read-write.c as a xstatfs() wrapper if we > do need this. I don't think it can. As per the comment, I thought QEMU knew something I didn't but I haven't seen any other reason for doing this. I'll remove it, thanks for the sanity jolt. Matt