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
WARNING: multiple messages have this Message-ID (diff)
From: Laszlo Ersek <lersek@redhat.com>
To: Bandan Das <bsd@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [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: 32+ 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-08 22:36 ` [Qemu-devel] " Bandan Das
2015-07-09 6:09 ` Paolo Bonzini
2015-07-09 6:09 ` [Qemu-devel] " Paolo Bonzini
2015-07-09 6:43 ` Laszlo Ersek
2015-07-09 6:43 ` [Qemu-devel] " Laszlo Ersek
2015-07-09 12:41 ` Paolo Bonzini
2015-07-09 12:41 ` [Qemu-devel] " Paolo Bonzini
2015-07-09 18:32 ` Bandan Das
2015-07-09 18:32 ` [Qemu-devel] " Bandan Das
2015-07-09 18:57 ` Laszlo Ersek
2015-07-09 18:57 ` [Qemu-devel] " Laszlo Ersek
2015-07-09 18:57 ` Laszlo Ersek
2015-07-09 20:02 ` Bandan Das
2015-07-09 20:02 ` [Qemu-devel] " Bandan Das
2015-07-09 20:02 ` Bandan Das
2015-07-09 20:15 ` Laszlo Ersek [this message]
2015-07-09 20:15 ` [Qemu-devel] " Laszlo Ersek
2015-07-10 3:37 ` Bandan Das
2015-07-10 3:37 ` [Qemu-devel] " Bandan Das
2015-07-10 3:37 ` Bandan Das
2015-07-10 14:13 ` Paolo Bonzini
2015-07-10 14:13 ` [Qemu-devel] " Paolo Bonzini
2015-07-10 14:57 ` Laszlo Ersek
2015-07-10 14:57 ` [Qemu-devel] " Laszlo Ersek
2015-07-10 14:59 ` Paolo Bonzini
2015-07-10 14:59 ` [Qemu-devel] " Paolo Bonzini
2015-07-10 15:06 ` Laszlo Ersek
2015-07-10 15:06 ` [Qemu-devel] " Laszlo Ersek
2015-07-10 15:06 ` Laszlo Ersek
2015-07-10 15:45 ` Bandan Das
2015-07-10 15:45 ` [Qemu-devel] " 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.