From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38063) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZDaUL-0005U3-EY for qemu-devel@nongnu.org; Fri, 10 Jul 2015 11:45:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZDaUI-00069l-5K for qemu-devel@nongnu.org; Fri, 10 Jul 2015 11:45:21 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52962) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZDaUH-00069Q-Pi for qemu-devel@nongnu.org; Fri, 10 Jul 2015 11:45:18 -0400 From: Bandan Das References: <559E101A.7080601@redhat.com> <559E180E.8080308@redhat.com> <559E6BE5.4030000@redhat.com> <559EC3FC.8050204@redhat.com> <559FD30C.4000209@redhat.com> <559FDD44.1020008@redhat.com> <559FDDC7.3060306@redhat.com> <559FDF8F.1020109@redhat.com> Date: Fri, 10 Jul 2015 11:45:15 -0400 In-Reply-To: <559FDF8F.1020109@redhat.com> (Laszlo Ersek's message of "Fri, 10 Jul 2015 17:06:55 +0200") Message-ID: MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH] KVM: x86: Add host physical address width capability List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laszlo Ersek Cc: Paolo Bonzini , linux-kernel@vger.kernel.org, kvm@vger.kernel.org, qemu-devel@nongnu.org Laszlo Ersek writes: > On 07/10/15 16:59, Paolo Bonzini wrote: >> >> >> On 10/07/2015 16:57, Laszlo Ersek wrote: >>>>> ... In any case, please understand that I'm not campaigning for this >>>>> warning :) IIRC the warning was your (very welcome!) idea after I >>>>> reported the problem; I'm just trying to ensure that the warning match >>>>> the exact issue I encountered. >>>> >>>> Yup. I think the right thing to do would be to hide memory above the >>>> limit. >>> How so? >>> >>> - The stack would not be doing what the user asks for. Pass -m , >>> and the guest would silently see less memory. If the user found out, >>> he'd immediately ask (or set out debugging) why. I think if the user's >>> request cannot be satisfied, the stack should fail hard. >> >> That's another possibility. I think both of them are wrong depending on >> _why_ you're using "-m " in the first place. >> >> Considering that this really happens (on Xeons) only for 1TB+ guests, > > I reported this issue because I ran into it with a ~64GB guest. From my > /proc/cpuinfo: > > model name : Intel(R) Core(TM) i7 CPU M 620 @ 2.67GHz > address sizes : 36 bits physical, 48 bits virtual > > I was specifically developing 64GB+ support for OVMF, and this > limitation caused me to think that there was a bug in my OVMF patches. > (There wasn't.) An error message from QEMU, advising me to turn off EPT, > would have saved me many hours. Right, I specifically reserved a system with 36 bits physical to reproduce this and it was very easy to reproduce. If it's a hardware bug, I would say, it's a very annoying one (if not serious). I wonder if Intel folks can chime in. > Thanks > Laszlo > >> it's probably just for debugging and then hiding the memory makes some >> sense. Actually, I agree with Laszlo here. Hiding memory is synonymous to forcing the user to use less for the -m argument as is failing. But failing and letting the user do it himself can save hours of debugging. Regards, The confused teenager who can't make up his mind. >> Paolo >>