From mboxrd@z Thu Jan 1 00:00:00 1970 From: Laszlo Ersek Subject: Re: [PATCH] KVM: x86: Add host physical address width capability Date: Fri, 10 Jul 2015 16:57:08 +0200 Message-ID: <559FDD44.1020008@redhat.com> References: <559E101A.7080601@redhat.com> <559E180E.8080308@redhat.com> <559E6BE5.4030000@redhat.com> <559EC3FC.8050204@redhat.com> <559FD30C.4000209@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, qemu-devel@nongnu.org To: Paolo Bonzini , Bandan Das Return-path: In-Reply-To: <559FD30C.4000209@redhat.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 07/10/15 16:13, Paolo Bonzini wrote: > > > On 09/07/2015 20:57, Laszlo Ersek wrote: >>> Without EPT, you don't >>> hit the processor limitation with your setup, but the user should nevertheless >>> still be notified. >> >> I disagree. > > FWIW, I also disagree (and it looks like Bandan disagrees with himself > now :)). > >>> In fact, I think shadow paging code should also emulate >>> this behavior if the gpa is out of range. >> >> I disagree. > > Same here. > >> There is no "out of range" gpa. QEMU allocates enough memory, and it >> should be completely transparent to the guest. The fact that it silently >> breaks with nested paging if the host processor doesn't have enough >> address bits is a bug (maybe a hardware bug, maybe a KVM bug; I'm not >> sure, but I suspect it's a hardware bug). > > It's a hardware bug, possibly due to some limitations in the physical > addresses that the TLB can store? I guess KVM could detect the > situation and fall back to sloooow shadow paging. > >> ... 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. - Assuming the user didn't find out, and the guest just worked (with less memory than the user asked for), then the hidden portion of the memory (that QEMU allocated nonetheless) would be just wasted, on the host system. (Especially with overcommit_memory=2 (which is the most prudent setting).) Thanks Laszlo > A kernel patch to query the limit is definitely necessary, but > it needs to return e.g. 48 for shadow paging (otherwise you could just > use CPUID). I'm not sure if the rest is possible with just QEMU, or it > requires help from the firmware. Probably yes. > > Paolo > From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52943) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZDZjs-00055O-Ki for qemu-devel@nongnu.org; Fri, 10 Jul 2015 10:57:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZDZjo-0000hs-FL for qemu-devel@nongnu.org; Fri, 10 Jul 2015 10:57:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:54341) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZDZjo-0000hb-9y for qemu-devel@nongnu.org; Fri, 10 Jul 2015 10:57:16 -0400 Message-ID: <559FDD44.1020008@redhat.com> Date: Fri, 10 Jul 2015 16:57:08 +0200 From: Laszlo Ersek MIME-Version: 1.0 References: <559E101A.7080601@redhat.com> <559E180E.8080308@redhat.com> <559E6BE5.4030000@redhat.com> <559EC3FC.8050204@redhat.com> <559FD30C.4000209@redhat.com> In-Reply-To: <559FD30C.4000209@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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: Paolo Bonzini , Bandan Das Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, qemu-devel@nongnu.org On 07/10/15 16:13, Paolo Bonzini wrote: > > > On 09/07/2015 20:57, Laszlo Ersek wrote: >>> Without EPT, you don't >>> hit the processor limitation with your setup, but the user should nevertheless >>> still be notified. >> >> I disagree. > > FWIW, I also disagree (and it looks like Bandan disagrees with himself > now :)). > >>> In fact, I think shadow paging code should also emulate >>> this behavior if the gpa is out of range. >> >> I disagree. > > Same here. > >> There is no "out of range" gpa. QEMU allocates enough memory, and it >> should be completely transparent to the guest. The fact that it silently >> breaks with nested paging if the host processor doesn't have enough >> address bits is a bug (maybe a hardware bug, maybe a KVM bug; I'm not >> sure, but I suspect it's a hardware bug). > > It's a hardware bug, possibly due to some limitations in the physical > addresses that the TLB can store? I guess KVM could detect the > situation and fall back to sloooow shadow paging. > >> ... 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. - Assuming the user didn't find out, and the guest just worked (with less memory than the user asked for), then the hidden portion of the memory (that QEMU allocated nonetheless) would be just wasted, on the host system. (Especially with overcommit_memory=2 (which is the most prudent setting).) Thanks Laszlo > A kernel patch to query the limit is definitely necessary, but > it needs to return e.g. 48 for shadow paging (otherwise you could just > use CPUID). I'm not sure if the rest is possible with just QEMU, or it > requires help from the firmware. Probably yes. > > Paolo >