From: Bandan Das <bsd@redhat.com>
To: Laszlo Ersek <lersek@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, 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: <jpg615ul1j8.fsf@linux.bootlegged.copy>
	<559E101A.7080601@redhat.com> <559E180E.8080308@redhat.com>
	<559E6BE5.4030000@redhat.com> <jpgy4ip6v1y.fsf@linux.bootlegged.copy>
	<559EC3FC.8050204@redhat.com>
Date: Thu, 09 Jul 2015 16:02:41 -0400
In-Reply-To: <559EC3FC.8050204@redhat.com> (Laszlo Ersek's message of "Thu, 09
	Jul 2015 20:57:00 +0200")
Message-ID: <jpgd2013xr2.fsf@linux.bootlegged.copy>
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
Content-Length: 2858
Lines: 64

Laszlo Ersek <lersek@redhat.com> 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.


> ... 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/