From: Laszlo Ersek <lersek@redhat.com>
To: Bandan Das <bsd@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
Date: Thu, 09 Jul 2015 22:15:54 +0200 [thread overview]
Message-ID: <559ED67A.7010600@redhat.com> (raw)
In-Reply-To: <jpgd2013xr2.fsf@linux.bootlegged.copy>
On 07/09/15 22:02, Bandan Das wrote:
> 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.
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
next prev parent reply other threads:[~2015-07-09 20:15 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-08 22:36 [PATCH] KVM: x86: Add host physical address width capability Bandan Das
2015-07-09 6:09 ` Paolo Bonzini
2015-07-09 6:43 ` Laszlo Ersek
2015-07-09 12:41 ` Paolo Bonzini
2015-07-09 18:32 ` Bandan Das
2015-07-09 18:57 ` Laszlo Ersek
2015-07-09 20:02 ` Bandan Das
2015-07-09 20:15 ` Laszlo Ersek [this message]
2015-07-10 3:37 ` Bandan Das
2015-07-10 14:13 ` Paolo Bonzini
2015-07-10 14:57 ` Laszlo Ersek
2015-07-10 14:59 ` Paolo Bonzini
2015-07-10 15:06 ` Laszlo Ersek
2015-07-10 15:45 ` Bandan Das
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=559ED67A.7010600@redhat.com \
--to=lersek@redhat.com \
--cc=bsd@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).