From: Marc Zyngier <maz@kernel.org>
To: Suzuki Poulose <suzuki.poulose@arm.com>
Cc: kvm@vger.kernel.org, kernel-team@android.com,
linux-arm-kernel@lists.infradead.org,
kvmarm@lists.cs.columbia.edu
Subject: Re: [PATCH] KVM: arm64: Cap default IPA size to the host's own size
Date: Tue, 09 Mar 2021 14:25:03 +0000 [thread overview]
Message-ID: <87lfawxv40.wl-maz@kernel.org> (raw)
In-Reply-To: <AB37EA2F-BAF2-4E0C-AD63-201CE480DFB2@arm.com>
Hi Suzuki,
On Tue, 09 Mar 2021 11:09:48 +0000,
Suzuki Poulose <suzuki.poulose@arm.com> wrote:
>
>
>
> > On 8 Mar 2021, at 17:46, Marc Zyngier <maz@kernel.org> wrote:
> >
> > KVM/arm64 has forever used a 40bit default IPA space, partially
> > due to its 32bit heritage (where the only choice is 40bit).
> >
> > However, there are implementations in the wild that have a *cough*
> > much smaller *cough* IPA space, which leads to a misprogramming of
> > VTCR_EL2, and a guest that is stuck on its first memory access
> > if userspace dares to ask for the default IPA setting (which most
> > VMMs do).
> >
> > Instead, cap the default IPA size to what the host can actually
> > do, and spit out a one-off message on the console. The boot warning
> > is turned into a more meaningfull message, and the new behaviour
> > is also documented.
> >
> > Although this is a userspace ABI change, it doesn't really change
> > much for userspace:
> >
> > - the guest couldn't run before this change, while it now has
> > a chance to if the memory range fits the reduced IPA space
> >
> > - a memory slot that was accepted because it did fit the default
> > IPA space but didn't fit the HW constraints is now properly
> > rejected
> >
> > The other thing that's left doing is to convince userspace to
> > actually use the IPA space setting instead of relying on the
> > antiquated default.
> >
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > ---
>
> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Thanks for that. Whilst I have your attention and given that you are
responsible for most of the variable IPA stuff... ;-)
I think we have another issue around the handling of our IPA
size. Let's say I create a VM with a 32bit IPA space. If I register a
2GB memslot at 0x8000000, I'm getting an error, which I think is
bogus.
I came to the conclusion that kvm_arch_prepare_memory_region() is a
bit overzealous when rejecting the memslot, and I used the following
patchlet to address it.
Does this seem sensible to you?
M.
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 77cb2d28f2a4..8711894db8c2 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -1312,8 +1312,7 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
* Prevent userspace from creating a memory region outside of the IPA
* space addressable by the KVM guest IPA space.
*/
- if (memslot->base_gfn + memslot->npages >=
- (kvm_phys_size(kvm) >> PAGE_SHIFT))
+ if ((memslot->base_gfn + memslot->npages) > (kvm_phys_size(kvm) >> PAGE_SHIFT))
return -EFAULT;
mmap_read_lock(current->mm);
--
Without deviation from the norm, progress is not possible.
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Suzuki Poulose <suzuki.poulose@arm.com>
Cc: kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org,
James Morse <james.morse@arm.com>,
Julien Thierry <julien.thierry.kdev@gmail.com>,
Alexandru Elisei <alexandru.elisei@arm.com>,
kernel-team@android.com
Subject: Re: [PATCH] KVM: arm64: Cap default IPA size to the host's own size
Date: Tue, 09 Mar 2021 14:25:03 +0000 [thread overview]
Message-ID: <87lfawxv40.wl-maz@kernel.org> (raw)
In-Reply-To: <AB37EA2F-BAF2-4E0C-AD63-201CE480DFB2@arm.com>
Hi Suzuki,
On Tue, 09 Mar 2021 11:09:48 +0000,
Suzuki Poulose <suzuki.poulose@arm.com> wrote:
>
>
>
> > On 8 Mar 2021, at 17:46, Marc Zyngier <maz@kernel.org> wrote:
> >
> > KVM/arm64 has forever used a 40bit default IPA space, partially
> > due to its 32bit heritage (where the only choice is 40bit).
> >
> > However, there are implementations in the wild that have a *cough*
> > much smaller *cough* IPA space, which leads to a misprogramming of
> > VTCR_EL2, and a guest that is stuck on its first memory access
> > if userspace dares to ask for the default IPA setting (which most
> > VMMs do).
> >
> > Instead, cap the default IPA size to what the host can actually
> > do, and spit out a one-off message on the console. The boot warning
> > is turned into a more meaningfull message, and the new behaviour
> > is also documented.
> >
> > Although this is a userspace ABI change, it doesn't really change
> > much for userspace:
> >
> > - the guest couldn't run before this change, while it now has
> > a chance to if the memory range fits the reduced IPA space
> >
> > - a memory slot that was accepted because it did fit the default
> > IPA space but didn't fit the HW constraints is now properly
> > rejected
> >
> > The other thing that's left doing is to convince userspace to
> > actually use the IPA space setting instead of relying on the
> > antiquated default.
> >
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > ---
>
> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Thanks for that. Whilst I have your attention and given that you are
responsible for most of the variable IPA stuff... ;-)
I think we have another issue around the handling of our IPA
size. Let's say I create a VM with a 32bit IPA space. If I register a
2GB memslot at 0x8000000, I'm getting an error, which I think is
bogus.
I came to the conclusion that kvm_arch_prepare_memory_region() is a
bit overzealous when rejecting the memslot, and I used the following
patchlet to address it.
Does this seem sensible to you?
M.
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 77cb2d28f2a4..8711894db8c2 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -1312,8 +1312,7 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
* Prevent userspace from creating a memory region outside of the IPA
* space addressable by the KVM guest IPA space.
*/
- if (memslot->base_gfn + memslot->npages >=
- (kvm_phys_size(kvm) >> PAGE_SHIFT))
+ if ((memslot->base_gfn + memslot->npages) > (kvm_phys_size(kvm) >> PAGE_SHIFT))
return -EFAULT;
mmap_read_lock(current->mm);
--
Without deviation from the norm, progress is not possible.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Suzuki Poulose <suzuki.poulose@arm.com>
Cc: kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org,
James Morse <james.morse@arm.com>,
Julien Thierry <julien.thierry.kdev@gmail.com>,
Alexandru Elisei <alexandru.elisei@arm.com>,
kernel-team@android.com
Subject: Re: [PATCH] KVM: arm64: Cap default IPA size to the host's own size
Date: Tue, 09 Mar 2021 14:25:03 +0000 [thread overview]
Message-ID: <87lfawxv40.wl-maz@kernel.org> (raw)
In-Reply-To: <AB37EA2F-BAF2-4E0C-AD63-201CE480DFB2@arm.com>
Hi Suzuki,
On Tue, 09 Mar 2021 11:09:48 +0000,
Suzuki Poulose <suzuki.poulose@arm.com> wrote:
>
>
>
> > On 8 Mar 2021, at 17:46, Marc Zyngier <maz@kernel.org> wrote:
> >
> > KVM/arm64 has forever used a 40bit default IPA space, partially
> > due to its 32bit heritage (where the only choice is 40bit).
> >
> > However, there are implementations in the wild that have a *cough*
> > much smaller *cough* IPA space, which leads to a misprogramming of
> > VTCR_EL2, and a guest that is stuck on its first memory access
> > if userspace dares to ask for the default IPA setting (which most
> > VMMs do).
> >
> > Instead, cap the default IPA size to what the host can actually
> > do, and spit out a one-off message on the console. The boot warning
> > is turned into a more meaningfull message, and the new behaviour
> > is also documented.
> >
> > Although this is a userspace ABI change, it doesn't really change
> > much for userspace:
> >
> > - the guest couldn't run before this change, while it now has
> > a chance to if the memory range fits the reduced IPA space
> >
> > - a memory slot that was accepted because it did fit the default
> > IPA space but didn't fit the HW constraints is now properly
> > rejected
> >
> > The other thing that's left doing is to convince userspace to
> > actually use the IPA space setting instead of relying on the
> > antiquated default.
> >
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > ---
>
> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Thanks for that. Whilst I have your attention and given that you are
responsible for most of the variable IPA stuff... ;-)
I think we have another issue around the handling of our IPA
size. Let's say I create a VM with a 32bit IPA space. If I register a
2GB memslot at 0x8000000, I'm getting an error, which I think is
bogus.
I came to the conclusion that kvm_arch_prepare_memory_region() is a
bit overzealous when rejecting the memslot, and I used the following
patchlet to address it.
Does this seem sensible to you?
M.
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 77cb2d28f2a4..8711894db8c2 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -1312,8 +1312,7 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
* Prevent userspace from creating a memory region outside of the IPA
* space addressable by the KVM guest IPA space.
*/
- if (memslot->base_gfn + memslot->npages >=
- (kvm_phys_size(kvm) >> PAGE_SHIFT))
+ if ((memslot->base_gfn + memslot->npages) > (kvm_phys_size(kvm) >> PAGE_SHIFT))
return -EFAULT;
mmap_read_lock(current->mm);
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2021-03-09 14:25 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-08 17:46 [PATCH] KVM: arm64: Cap default IPA size to the host's own size Marc Zyngier
2021-03-08 17:46 ` Marc Zyngier
2021-03-08 17:46 ` Marc Zyngier
2021-03-09 11:09 ` Suzuki Poulose
2021-03-09 11:09 ` Suzuki Poulose
2021-03-09 11:09 ` Suzuki Poulose
2021-03-09 14:25 ` Marc Zyngier [this message]
2021-03-09 14:25 ` Marc Zyngier
2021-03-09 14:25 ` Marc Zyngier
2021-03-09 11:26 ` Will Deacon
2021-03-09 11:26 ` Will Deacon
2021-03-09 11:26 ` Will Deacon
2021-03-09 11:35 ` Marc Zyngier
2021-03-09 11:35 ` Marc Zyngier
2021-03-09 11:35 ` Marc Zyngier
2021-03-09 11:40 ` Will Deacon
2021-03-09 11:40 ` Will Deacon
2021-03-09 11:40 ` Will Deacon
2021-03-09 13:20 ` Andrew Jones
2021-03-09 13:20 ` Andrew Jones
2021-03-09 13:20 ` Andrew Jones
2021-03-09 13:43 ` Marc Zyngier
2021-03-09 13:43 ` Marc Zyngier
2021-03-09 13:43 ` Marc Zyngier
2021-03-09 14:29 ` Andrew Jones
2021-03-09 14:29 ` Andrew Jones
2021-03-09 14:29 ` Andrew Jones
2021-03-09 14:46 ` Marc Zyngier
2021-03-09 14:46 ` Marc Zyngier
2021-03-09 14:46 ` Marc Zyngier
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=87lfawxv40.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=kernel-team@android.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=suzuki.poulose@arm.com \
/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.