From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: Balbir Singh <bsingharora@gmail.com>,
kvm-ppc@vger.kernel.org, kvm@vger.kernel.org
Cc: linuxppc-dev <linuxppc-dev@ozlabs.org>,
Paolo Bonzini <pbonzini@redhat.com>,
Paul Mackerras <paulus@samba.org>, Radim <rkrcmar@redhat.com>
Subject: Re: [PATCH v2] KVM/PPC Patch for KVM issue in real mode
Date: Wed, 30 Nov 2016 08:47:06 +0000 [thread overview]
Message-ID: <8760n5icw5.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <20a3e138-8a6e-6ad8-b9ba-ec8332f011a5@gmail.com>
Balbir Singh <bsingharora@gmail.com> writes:
> Some KVM functions for book3s_hv are called in real mode.
> In real mode the top 4 bits of the address space are ignored,
> hence an address beginning with 0xc0000000+offset is the
> same as 0xd0000000+offset. The issue was observed when
> a kvm memslot resolution lead to random values when
> access from kvmppc_h_enter(). The issue is hit if the
> KVM host is running with a page size of 4K, since
> kvzalloc() looks at size < PAGE_SIZE. On systems with
> 64K the issue is not observed easily, it largely depends
> on the size of the structure being allocated.
>
> The proposed fix moves all KVM allocations for book3s_hv
> to kzalloc() until all structures used in real mode are
> audited. For safety allocations are moved to kmalloc
> space. The impact is a large allocation on systems with
> 4K page size.
We did such access using *real_vmalloc_addr(void *x). So you are
suggesting here is we don't do that for all code path ?
Do you have a stack dump for which you identified the issue ?
>
> Signed-off-by: Balbir Singh <bsingharora@gmail.com>
> ---
> Changelog v2:
> Fix build failures reported by the kbuild test robot
> http://www.spinics.net/lists/kvm/msg141727.html
>
> arch/powerpc/include/asm/kvm_host.h | 19 +++++++++++++++++++
> include/linux/kvm_host.h | 11 +++++++++++
> virt/kvm/kvm_main.c | 2 +-
> 3 files changed, 31 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
> index f15713a..53f5172 100644
> --- a/arch/powerpc/include/asm/kvm_host.h
> +++ b/arch/powerpc/include/asm/kvm_host.h
> @@ -734,6 +734,25 @@ struct kvm_vcpu_arch {
> #define __KVM_HAVE_ARCH_WQP
> #define __KVM_HAVE_CREATE_DEVICE
>
> +#ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
> +#define __KVM_HAVE_ARCH_VZALLOC_OVERRIDE
do we need that OVERRIDE ? We usually have HAVE_ARCH_KVM_VZALLOC
or just say #ifndef kvm_arch_vzalloc ?
> +
> +/*
> + * KVM uses some of these data structures -- the ones
> + * from kvzalloc() in real mode. If the data structure
> + * happens to come from a vmalloc'd range then its access
> + * in real mode will lead to problems due to the aliasing
> + * issue - (top 4 bits are ignore).
> + * A 0xd000+offset will point to a 0xc000+offset in realmode
> + * Hence we want our data structures from come from kmalloc'd
> + * regions, so that we don't have these aliasing issues
> + */
> +static inline void *kvm_arch_vzalloc(unsigned long size)
> +{
> + return kzalloc(size, GFP_KERNEL);
> +}
> +#endif
....
-aneesh
WARNING: multiple messages have this Message-ID (diff)
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: Balbir Singh <bsingharora@gmail.com>,
kvm-ppc@vger.kernel.org, kvm@vger.kernel.org
Cc: linuxppc-dev <linuxppc-dev@ozlabs.org>,
Paolo Bonzini <pbonzini@redhat.com>,
Paul Mackerras <paulus@samba.org>, Radim <rkrcmar@redhat.com>
Subject: Re: [PATCH v2] KVM/PPC Patch for KVM issue in real mode
Date: Wed, 30 Nov 2016 14:05:06 +0530 [thread overview]
Message-ID: <8760n5icw5.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <20a3e138-8a6e-6ad8-b9ba-ec8332f011a5@gmail.com>
Balbir Singh <bsingharora@gmail.com> writes:
> Some KVM functions for book3s_hv are called in real mode.
> In real mode the top 4 bits of the address space are ignored,
> hence an address beginning with 0xc0000000+offset is the
> same as 0xd0000000+offset. The issue was observed when
> a kvm memslot resolution lead to random values when
> access from kvmppc_h_enter(). The issue is hit if the
> KVM host is running with a page size of 4K, since
> kvzalloc() looks at size < PAGE_SIZE. On systems with
> 64K the issue is not observed easily, it largely depends
> on the size of the structure being allocated.
>
> The proposed fix moves all KVM allocations for book3s_hv
> to kzalloc() until all structures used in real mode are
> audited. For safety allocations are moved to kmalloc
> space. The impact is a large allocation on systems with
> 4K page size.
We did such access using *real_vmalloc_addr(void *x). So you are
suggesting here is we don't do that for all code path ?
Do you have a stack dump for which you identified the issue ?
>
> Signed-off-by: Balbir Singh <bsingharora@gmail.com>
> ---
> Changelog v2:
> Fix build failures reported by the kbuild test robot
> http://www.spinics.net/lists/kvm/msg141727.html
>
> arch/powerpc/include/asm/kvm_host.h | 19 +++++++++++++++++++
> include/linux/kvm_host.h | 11 +++++++++++
> virt/kvm/kvm_main.c | 2 +-
> 3 files changed, 31 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
> index f15713a..53f5172 100644
> --- a/arch/powerpc/include/asm/kvm_host.h
> +++ b/arch/powerpc/include/asm/kvm_host.h
> @@ -734,6 +734,25 @@ struct kvm_vcpu_arch {
> #define __KVM_HAVE_ARCH_WQP
> #define __KVM_HAVE_CREATE_DEVICE
>
> +#ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
> +#define __KVM_HAVE_ARCH_VZALLOC_OVERRIDE
do we need that OVERRIDE ? We usually have HAVE_ARCH_KVM_VZALLOC
or just say #ifndef kvm_arch_vzalloc ?
> +
> +/*
> + * KVM uses some of these data structures -- the ones
> + * from kvzalloc() in real mode. If the data structure
> + * happens to come from a vmalloc'd range then its access
> + * in real mode will lead to problems due to the aliasing
> + * issue - (top 4 bits are ignore).
> + * A 0xd000+offset will point to a 0xc000+offset in realmode
> + * Hence we want our data structures from come from kmalloc'd
> + * regions, so that we don't have these aliasing issues
> + */
> +static inline void *kvm_arch_vzalloc(unsigned long size)
> +{
> + return kzalloc(size, GFP_KERNEL);
> +}
> +#endif
....
-aneesh
next prev parent reply other threads:[~2016-11-30 8:47 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-30 4:11 [PATCH v2] KVM/PPC Patch for KVM issue in real mode Balbir Singh
2016-11-30 4:11 ` Balbir Singh
2016-11-30 8:35 ` Aneesh Kumar K.V [this message]
2016-11-30 8:47 ` Aneesh Kumar K.V
2016-11-30 9:09 ` Balbir Singh
2016-11-30 9:09 ` Balbir Singh
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=8760n5icw5.fsf@linux.vnet.ibm.com \
--to=aneesh.kumar@linux.vnet.ibm.com \
--cc=bsingharora@gmail.com \
--cc=kvm-ppc@vger.kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=paulus@samba.org \
--cc=pbonzini@redhat.com \
--cc=rkrcmar@redhat.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.