Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753733AbbGIUQF (ORCPT ); Thu, 9 Jul 2015 16:16:05 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42415 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751619AbbGIUP4 (ORCPT ); Thu, 9 Jul 2015 16:15:56 -0400 Message-ID: <559ED67A.7010600@redhat.com> Date: Thu, 09 Jul 2015 22:15:54 +0200 From: Laszlo Ersek User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Bandan Das CC: Paolo Bonzini , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, qemu-devel@nongnu.org Subject: Re: [PATCH] KVM: x86: Add host physical address width capability References: <559E101A.7080601@redhat.com> <559E180E.8080308@redhat.com> <559E6BE5.4030000@redhat.com> <559EC3FC.8050204@redhat.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2752 Lines: 65 On 07/09/15 22:02, Bandan Das wrote: > Laszlo Ersek writes: > ... >> Yes. >> >>> Without EPT, you don't >>> hit the processor limitation with your setup, but the user should nevertheless >>> still be notified. >> >> I disagree. >> >>> In fact, I think shadow paging code should also emulate >>> this behavior if the gpa is out of range. >> >> I disagree. >> >> 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). In any case the guest >> shouldn't care at all. It is a *virtual* machine, and the VMM should lie >> to it plausibly enough. How much RAM, and how many phys address bits the >> host has, is a performance question, but it should not be a correctness >> question. A 256 GB guest should run (slowly, but correctly) on a laptop >> that has only 4 GB of RAM and only 36 phys addr bits, but plenty of swap >> space. >> >> Because otherwise your argument could be extrapolated as "TCG should >> break too if the gpa is 'out of range'". >> >> So, I disagree. Whatever memory you give to the guest should just work >> (unless of course you want to emulate a small address width for the >> *VCPU*, but that's absolutely not the use case here). What we have here >> is a leaky abstraction: a PCPU limitation giving away a lie that the >> guest should never notice. The guest should be able to use all memory >> that was specified with QEMU's -m, regardless of TCG vs. KVM-without-EPT >> vs. KVM-with-EPT. If the last case cannot work (due to hardware >> limitations), that's fine, but then (and only then) a warning should be >> printed. > > Hmm... Ok, I understand your point. So, this is more like a EPT > limitation/bug in that Qemu isn't complaining about the memory assigned > to the guest but EPT code is breaking owing to the processor physical > address width. Exactly. > And honestly, I now think that this patch just makes the whole > situation more confusing :) I am wondering if it's just possible for kvm to > simply throw an error like a EPT misconfiguration or something .. > > Or in other words, if using a hardware assisted mechanism is just not > possible, KVM will simply not let it run instead of letting a guest > stuck in boot. That would be the best solution. Thanks Laszlo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/