Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752403AbbGJDiD (ORCPT ); Thu, 9 Jul 2015 23:38:03 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47253 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750744AbbGJDhz (ORCPT ); Thu, 9 Jul 2015 23:37:55 -0400 From: Bandan Das To: Laszlo Ersek 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> Date: Thu, 09 Jul 2015 23:37:53 -0400 In-Reply-To: (Bandan Das's message of "Thu, 09 Jul 2015 16:02:41 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3691 Lines: 80 Bandan Das writes: > 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. 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. I noticed that when the guest gets stuck, trace shows an endless loop of EXTERNAL_INTERRUPT exits with code 14 (PF). There's a note in 28.2.2 of the spec that "No processors supporting the Intel64 architecture support more than 48 physical-address bits.. An attempt to use such an address causes a page fault". So, my first guess was to print out the guest physical address. That seems to be well beyond the range and is always 0xff000 (when the guest is stuck). The other thing I can think of is the EPT entries have bits in the 51:N range set which is reserved and always 0. I haven't verified but it looks like there's ept_misconfig_inspect_spte() that should already catch this condition. I am out of ideas for today :) > >> ... 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. >> >> 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/