Re: [PATCH 3/4] PF: Provide additional direct page notification
On 10.07.2013, at 12:48, Gleb Natapov wrote: > On Wed, Jul 10, 2013 at 12:45:59PM +0200, Alexander Graf wrote: >> >> On 10.07.2013, at 12:42, Gleb Natapov wrote: >> >>> On Wed, Jul 10, 2013 at 12:39:01PM +0200, Alexander Graf wrote: On 09.07.2013, at 18:01, Christian Borntraeger wrote: > On 09/07/13 15:56, Dominik Dingel wrote: >> By setting a Kconfig option, the architecture can control when >> guest notifications will be presented by the apf backend. >> So there is the default batch mechanism, working as before, where the >> vcpu thread >> should pull in this information. On the other hand there is now the >> direct >> mechanism, this will directly push the information to the guest. >> >> Still the vcpu thread should call check_completion to cleanup leftovers, >> that leaves most of the common code untouched. >> >> Signed-off-by: Dominik Dingel > > Acked-by: Christian Borntraeger > for the "why". We want to use the existing architectured interface. Shouldn't this be a runtime option? >>> Why? What is the advantage of using sync delivery when HW can do it >>> async? >> >> What's the advantage of having an option at all then? Who selects it? >> > x86 is stupid and cannot deliver the even asynchronously. Platform that > can do it select the option. We're in generic code. S390x enables it. X86 does not. That was the missing link! Thanks a lot and sorry for the fuss :). Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] PF: Provide additional direct page notification
On 10.07.2013, at 12:49, Christian Borntraeger wrote: > On 10/07/13 12:39, Alexander Graf wrote: >> >> On 09.07.2013, at 18:01, Christian Borntraeger wrote: >> >>> On 09/07/13 15:56, Dominik Dingel wrote: By setting a Kconfig option, the architecture can control when guest notifications will be presented by the apf backend. So there is the default batch mechanism, working as before, where the vcpu thread should pull in this information. On the other hand there is now the direct mechanism, this will directly push the information to the guest. Still the vcpu thread should call check_completion to cleanup leftovers, that leaves most of the common code untouched. Signed-off-by: Dominik Dingel >>> >>> Acked-by: Christian Borntraeger >>> for the "why". We want to use the existing architectured interface. >> >> Shouldn't this be a runtime option? > > This is an a) or b) depending on the architecture. So making this a kconfig > option is the most sane approach no? I guess I'm just missing the patch that actually selects it. Last thing I remember you can have a kernel configured for s390x that runs on any 64bit capable system out there. What would you select? If that kernel runs on newer hardware, it would be able to do async pf, no? There's a good chance I simply miss a critical component here :). Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] PF: Provide additional direct page notification
On Wed, Jul 10, 2013 at 12:45:59PM +0200, Alexander Graf wrote: > > On 10.07.2013, at 12:42, Gleb Natapov wrote: > > > On Wed, Jul 10, 2013 at 12:39:01PM +0200, Alexander Graf wrote: > >> > >> On 09.07.2013, at 18:01, Christian Borntraeger wrote: > >> > >>> On 09/07/13 15:56, Dominik Dingel wrote: > By setting a Kconfig option, the architecture can control when > guest notifications will be presented by the apf backend. > So there is the default batch mechanism, working as before, where the > vcpu thread > should pull in this information. On the other hand there is now the > direct > mechanism, this will directly push the information to the guest. > > Still the vcpu thread should call check_completion to cleanup leftovers, > that leaves most of the common code untouched. > > Signed-off-by: Dominik Dingel > >>> > >>> Acked-by: Christian Borntraeger > >>> for the "why". We want to use the existing architectured interface. > >> > >> Shouldn't this be a runtime option? > >> > > Why? What is the advantage of using sync delivery when HW can do it > > async? > > What's the advantage of having an option at all then? Who selects it? > x86 is stupid and cannot deliver the even asynchronously. Platform that can do it select the option. -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] PF: Provide additional direct page notification
On 10/07/13 12:39, Alexander Graf wrote: > > On 09.07.2013, at 18:01, Christian Borntraeger wrote: > >> On 09/07/13 15:56, Dominik Dingel wrote: >>> By setting a Kconfig option, the architecture can control when >>> guest notifications will be presented by the apf backend. >>> So there is the default batch mechanism, working as before, where the vcpu >>> thread >>> should pull in this information. On the other hand there is now the direct >>> mechanism, this will directly push the information to the guest. >>> >>> Still the vcpu thread should call check_completion to cleanup leftovers, >>> that leaves most of the common code untouched. >>> >>> Signed-off-by: Dominik Dingel >> >> Acked-by: Christian Borntraeger >> for the "why". We want to use the existing architectured interface. > > Shouldn't this be a runtime option? This is an a) or b) depending on the architecture. So making this a kconfig option is the most sane approach no? Christian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] PF: Provide additional direct page notification
On 10.07.2013, at 12:42, Gleb Natapov wrote: > On Wed, Jul 10, 2013 at 12:39:01PM +0200, Alexander Graf wrote: >> >> On 09.07.2013, at 18:01, Christian Borntraeger wrote: >> >>> On 09/07/13 15:56, Dominik Dingel wrote: By setting a Kconfig option, the architecture can control when guest notifications will be presented by the apf backend. So there is the default batch mechanism, working as before, where the vcpu thread should pull in this information. On the other hand there is now the direct mechanism, this will directly push the information to the guest. Still the vcpu thread should call check_completion to cleanup leftovers, that leaves most of the common code untouched. Signed-off-by: Dominik Dingel >>> >>> Acked-by: Christian Borntraeger >>> for the "why". We want to use the existing architectured interface. >> >> Shouldn't this be a runtime option? >> > Why? What is the advantage of using sync delivery when HW can do it > async? What's the advantage of having an option at all then? Who selects it? Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] PF: Provide additional direct page notification
On Wed, Jul 10, 2013 at 12:39:01PM +0200, Alexander Graf wrote: > > On 09.07.2013, at 18:01, Christian Borntraeger wrote: > > > On 09/07/13 15:56, Dominik Dingel wrote: > >> By setting a Kconfig option, the architecture can control when > >> guest notifications will be presented by the apf backend. > >> So there is the default batch mechanism, working as before, where the vcpu > >> thread > >> should pull in this information. On the other hand there is now the direct > >> mechanism, this will directly push the information to the guest. > >> > >> Still the vcpu thread should call check_completion to cleanup leftovers, > >> that leaves most of the common code untouched. > >> > >> Signed-off-by: Dominik Dingel > > > > Acked-by: Christian Borntraeger > > for the "why". We want to use the existing architectured interface. > > Shouldn't this be a runtime option? > Why? What is the advantage of using sync delivery when HW can do it async? -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] PF: Provide additional direct page notification
On 09.07.2013, at 18:01, Christian Borntraeger wrote: > On 09/07/13 15:56, Dominik Dingel wrote: >> By setting a Kconfig option, the architecture can control when >> guest notifications will be presented by the apf backend. >> So there is the default batch mechanism, working as before, where the vcpu >> thread >> should pull in this information. On the other hand there is now the direct >> mechanism, this will directly push the information to the guest. >> >> Still the vcpu thread should call check_completion to cleanup leftovers, >> that leaves most of the common code untouched. >> >> Signed-off-by: Dominik Dingel > > Acked-by: Christian Borntraeger > for the "why". We want to use the existing architectured interface. Shouldn't this be a runtime option? Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] PF: Provide additional direct page notification
On 09.07.2013, at 18:01, Christian Borntraeger wrote: On 09/07/13 15:56, Dominik Dingel wrote: By setting a Kconfig option, the architecture can control when guest notifications will be presented by the apf backend. So there is the default batch mechanism, working as before, where the vcpu thread should pull in this information. On the other hand there is now the direct mechanism, this will directly push the information to the guest. Still the vcpu thread should call check_completion to cleanup leftovers, that leaves most of the common code untouched. Signed-off-by: Dominik Dingel din...@linux.vnet.ibm.com Acked-by: Christian Borntraeger borntrae...@de.ibm.com for the why. We want to use the existing architectured interface. Shouldn't this be a runtime option? Alex -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] PF: Provide additional direct page notification
On Wed, Jul 10, 2013 at 12:39:01PM +0200, Alexander Graf wrote: On 09.07.2013, at 18:01, Christian Borntraeger wrote: On 09/07/13 15:56, Dominik Dingel wrote: By setting a Kconfig option, the architecture can control when guest notifications will be presented by the apf backend. So there is the default batch mechanism, working as before, where the vcpu thread should pull in this information. On the other hand there is now the direct mechanism, this will directly push the information to the guest. Still the vcpu thread should call check_completion to cleanup leftovers, that leaves most of the common code untouched. Signed-off-by: Dominik Dingel din...@linux.vnet.ibm.com Acked-by: Christian Borntraeger borntrae...@de.ibm.com for the why. We want to use the existing architectured interface. Shouldn't this be a runtime option? Why? What is the advantage of using sync delivery when HW can do it async? -- Gleb. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] PF: Provide additional direct page notification
On 10.07.2013, at 12:42, Gleb Natapov wrote: On Wed, Jul 10, 2013 at 12:39:01PM +0200, Alexander Graf wrote: On 09.07.2013, at 18:01, Christian Borntraeger wrote: On 09/07/13 15:56, Dominik Dingel wrote: By setting a Kconfig option, the architecture can control when guest notifications will be presented by the apf backend. So there is the default batch mechanism, working as before, where the vcpu thread should pull in this information. On the other hand there is now the direct mechanism, this will directly push the information to the guest. Still the vcpu thread should call check_completion to cleanup leftovers, that leaves most of the common code untouched. Signed-off-by: Dominik Dingel din...@linux.vnet.ibm.com Acked-by: Christian Borntraeger borntrae...@de.ibm.com for the why. We want to use the existing architectured interface. Shouldn't this be a runtime option? Why? What is the advantage of using sync delivery when HW can do it async? What's the advantage of having an option at all then? Who selects it? Alex -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] PF: Provide additional direct page notification
On 10/07/13 12:39, Alexander Graf wrote: On 09.07.2013, at 18:01, Christian Borntraeger wrote: On 09/07/13 15:56, Dominik Dingel wrote: By setting a Kconfig option, the architecture can control when guest notifications will be presented by the apf backend. So there is the default batch mechanism, working as before, where the vcpu thread should pull in this information. On the other hand there is now the direct mechanism, this will directly push the information to the guest. Still the vcpu thread should call check_completion to cleanup leftovers, that leaves most of the common code untouched. Signed-off-by: Dominik Dingel din...@linux.vnet.ibm.com Acked-by: Christian Borntraeger borntrae...@de.ibm.com for the why. We want to use the existing architectured interface. Shouldn't this be a runtime option? This is an a) or b) depending on the architecture. So making this a kconfig option is the most sane approach no? Christian -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] PF: Provide additional direct page notification
On Wed, Jul 10, 2013 at 12:45:59PM +0200, Alexander Graf wrote: On 10.07.2013, at 12:42, Gleb Natapov wrote: On Wed, Jul 10, 2013 at 12:39:01PM +0200, Alexander Graf wrote: On 09.07.2013, at 18:01, Christian Borntraeger wrote: On 09/07/13 15:56, Dominik Dingel wrote: By setting a Kconfig option, the architecture can control when guest notifications will be presented by the apf backend. So there is the default batch mechanism, working as before, where the vcpu thread should pull in this information. On the other hand there is now the direct mechanism, this will directly push the information to the guest. Still the vcpu thread should call check_completion to cleanup leftovers, that leaves most of the common code untouched. Signed-off-by: Dominik Dingel din...@linux.vnet.ibm.com Acked-by: Christian Borntraeger borntrae...@de.ibm.com for the why. We want to use the existing architectured interface. Shouldn't this be a runtime option? Why? What is the advantage of using sync delivery when HW can do it async? What's the advantage of having an option at all then? Who selects it? x86 is stupid and cannot deliver the even asynchronously. Platform that can do it select the option. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] PF: Provide additional direct page notification
On 10.07.2013, at 12:49, Christian Borntraeger wrote: On 10/07/13 12:39, Alexander Graf wrote: On 09.07.2013, at 18:01, Christian Borntraeger wrote: On 09/07/13 15:56, Dominik Dingel wrote: By setting a Kconfig option, the architecture can control when guest notifications will be presented by the apf backend. So there is the default batch mechanism, working as before, where the vcpu thread should pull in this information. On the other hand there is now the direct mechanism, this will directly push the information to the guest. Still the vcpu thread should call check_completion to cleanup leftovers, that leaves most of the common code untouched. Signed-off-by: Dominik Dingel din...@linux.vnet.ibm.com Acked-by: Christian Borntraeger borntrae...@de.ibm.com for the why. We want to use the existing architectured interface. Shouldn't this be a runtime option? This is an a) or b) depending on the architecture. So making this a kconfig option is the most sane approach no? I guess I'm just missing the patch that actually selects it. Last thing I remember you can have a kernel configured for s390x that runs on any 64bit capable system out there. What would you select? If that kernel runs on newer hardware, it would be able to do async pf, no? There's a good chance I simply miss a critical component here :). Alex -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] PF: Provide additional direct page notification
On 10.07.2013, at 12:48, Gleb Natapov wrote: On Wed, Jul 10, 2013 at 12:45:59PM +0200, Alexander Graf wrote: On 10.07.2013, at 12:42, Gleb Natapov wrote: On Wed, Jul 10, 2013 at 12:39:01PM +0200, Alexander Graf wrote: On 09.07.2013, at 18:01, Christian Borntraeger wrote: On 09/07/13 15:56, Dominik Dingel wrote: By setting a Kconfig option, the architecture can control when guest notifications will be presented by the apf backend. So there is the default batch mechanism, working as before, where the vcpu thread should pull in this information. On the other hand there is now the direct mechanism, this will directly push the information to the guest. Still the vcpu thread should call check_completion to cleanup leftovers, that leaves most of the common code untouched. Signed-off-by: Dominik Dingel din...@linux.vnet.ibm.com Acked-by: Christian Borntraeger borntrae...@de.ibm.com for the why. We want to use the existing architectured interface. Shouldn't this be a runtime option? Why? What is the advantage of using sync delivery when HW can do it async? What's the advantage of having an option at all then? Who selects it? x86 is stupid and cannot deliver the even asynchronously. Platform that can do it select the option. We're in generic code. S390x enables it. X86 does not. That was the missing link! Thanks a lot and sorry for the fuss :). Alex -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] PF: Provide additional direct page notification
On 09/07/13 15:56, Dominik Dingel wrote: > By setting a Kconfig option, the architecture can control when > guest notifications will be presented by the apf backend. > So there is the default batch mechanism, working as before, where the vcpu > thread > should pull in this information. On the other hand there is now the direct > mechanism, this will directly push the information to the guest. > > Still the vcpu thread should call check_completion to cleanup leftovers, > that leaves most of the common code untouched. > > Signed-off-by: Dominik Dingel Acked-by: Christian Borntraeger for the "why". We want to use the existing architectured interface. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] PF: Provide additional direct page notification
On 09/07/13 15:56, Dominik Dingel wrote: By setting a Kconfig option, the architecture can control when guest notifications will be presented by the apf backend. So there is the default batch mechanism, working as before, where the vcpu thread should pull in this information. On the other hand there is now the direct mechanism, this will directly push the information to the guest. Still the vcpu thread should call check_completion to cleanup leftovers, that leaves most of the common code untouched. Signed-off-by: Dominik Dingel din...@linux.vnet.ibm.com Acked-by: Christian Borntraeger borntrae...@de.ibm.com for the why. We want to use the existing architectured interface. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] PF: Provide additional direct page notification
On Fri, Jul 05, 2013 at 10:55:53PM +0200, Dominik Dingel wrote:
> By setting a Kconfig option, the architecture can control when
> guest notifications will be presented by the apf backend.
> So there is the default batch mechanism, working as before, where the vcpu
> thread
> should pull in this information. On the other hand there is now the direct
> mechanism, this will directly push the information to the guest.
>
> Still the vcpu thread should call check_completion to cleanup leftovers,
> that leaves most of the common code untouched.
>
> Signed-off-by: Dominik Dingel
> ---
> arch/x86/kvm/mmu.c | 2 +-
> include/linux/kvm_host.h | 2 +-
> virt/kvm/Kconfig | 4
> virt/kvm/async_pf.c | 22 +++---
> 4 files changed, 25 insertions(+), 5 deletions(-)
>
> diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
> index 0d094da..b8632e9 100644
> --- a/arch/x86/kvm/mmu.c
> +++ b/arch/x86/kvm/mmu.c
> @@ -3343,7 +3343,7 @@ static int kvm_arch_setup_async_pf(struct kvm_vcpu
> *vcpu, gva_t gva, gfn_t gfn)
> arch.direct_map = vcpu->arch.mmu.direct_map;
> arch.cr3 = vcpu->arch.mmu.get_cr3(vcpu);
>
> - return kvm_setup_async_pf(vcpu, gva, gfn, );
> + return kvm_setup_async_pf(vcpu, gva, gfn_to_hva(vcpu->kvm, gfn), );
> }
>
> static bool can_do_async_pf(struct kvm_vcpu *vcpu)
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index 210f493..969d575 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -175,7 +175,7 @@ struct kvm_async_pf {
>
> void kvm_clear_async_pf_completion_queue(struct kvm_vcpu *vcpu);
> void kvm_check_async_pf_completion(struct kvm_vcpu *vcpu);
> -int kvm_setup_async_pf(struct kvm_vcpu *vcpu, gva_t gva, gfn_t gfn,
> +int kvm_setup_async_pf(struct kvm_vcpu *vcpu, gva_t gva, unsigned long hva,
> struct kvm_arch_async_pf *arch);
> int kvm_async_pf_wakeup_all(struct kvm_vcpu *vcpu);
> #endif
> diff --git a/virt/kvm/Kconfig b/virt/kvm/Kconfig
> index 779262f..715e6b5 100644
> --- a/virt/kvm/Kconfig
> +++ b/virt/kvm/Kconfig
> @@ -22,6 +22,10 @@ config KVM_MMIO
> config KVM_ASYNC_PF
> bool
>
> +# Toggle to switch between direct notification and batch job
> +config KVM_ASYNC_PF_DIRECT
> + bool
> +
> config HAVE_KVM_MSI
> bool
>
> diff --git a/virt/kvm/async_pf.c b/virt/kvm/async_pf.c
> index ea475cd..b8df37a 100644
> --- a/virt/kvm/async_pf.c
> +++ b/virt/kvm/async_pf.c
> @@ -28,6 +28,21 @@
> #include "async_pf.h"
> #include
>
> +static inline void kvm_async_page_direct_present(struct kvm_vcpu *vcpu,
> + struct kvm_async_pf *work)
> +{
> +#ifdef CONFIG_KVM_ASYNC_PF_DIRECT
> + kvm_arch_async_page_present(vcpu, work);
> +#endif
> +}
> +static inline void kvm_async_page_batch_present(struct kvm_vcpu *vcpu,
> + struct kvm_async_pf *work)
> +{
> +#ifndef CONFIG_KVM_ASYNC_PF_DIRECT
> + kvm_arch_async_page_present(vcpu, work);
> +#endif
> +}
> +
I would call them kvm_async_page_present_(async|sync)().
Hmm, to much "sync" in each function name, but I still think it is
better.
> static struct kmem_cache *async_pf_cache;
>
> int kvm_async_pf_init(void)
> @@ -70,6 +85,7 @@ static void async_pf_execute(struct work_struct *work)
> down_read(>mmap_sem);
> get_user_pages(current, mm, addr, 1, 1, 0, , NULL);
> up_read(>mmap_sem);
> + kvm_async_page_direct_present(vcpu, apf);
> unuse_mm(mm);
>
> spin_lock(>async_pf.lock);
> @@ -134,7 +150,7 @@ void kvm_check_async_pf_completion(struct kvm_vcpu *vcpu)
>
> if (work->page)
> kvm_arch_async_page_ready(vcpu, work);
> - kvm_arch_async_page_present(vcpu, work);
> + kvm_async_page_batch_present(vcpu, work);
>
> list_del(>queue);
> vcpu->async_pf.queued--;
> @@ -144,7 +160,7 @@ void kvm_check_async_pf_completion(struct kvm_vcpu *vcpu)
> }
> }
>
> -int kvm_setup_async_pf(struct kvm_vcpu *vcpu, gva_t gva, gfn_t gfn,
> +int kvm_setup_async_pf(struct kvm_vcpu *vcpu, gva_t gva, unsigned long hva,
> struct kvm_arch_async_pf *arch)
> {
> struct kvm_async_pf *work;
> @@ -166,7 +182,7 @@ int kvm_setup_async_pf(struct kvm_vcpu *vcpu, gva_t gva,
> gfn_t gfn,
> work->done = false;
> work->vcpu = vcpu;
> work->gva = gva;
> - work->addr = gfn_to_hva(vcpu->kvm, gfn);
> + work->addr = hva;
> work->arch = *arch;
> work->mm = current->mm;
> atomic_inc(>mm->mm_count);
> --
> 1.8.2.2
--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] PF: Provide additional direct page notification
On Fri, Jul 05, 2013 at 10:55:53PM +0200, Dominik Dingel wrote:
By setting a Kconfig option, the architecture can control when
guest notifications will be presented by the apf backend.
So there is the default batch mechanism, working as before, where the vcpu
thread
should pull in this information. On the other hand there is now the direct
mechanism, this will directly push the information to the guest.
Still the vcpu thread should call check_completion to cleanup leftovers,
that leaves most of the common code untouched.
Signed-off-by: Dominik Dingel din...@linux.vnet.ibm.com
---
arch/x86/kvm/mmu.c | 2 +-
include/linux/kvm_host.h | 2 +-
virt/kvm/Kconfig | 4
virt/kvm/async_pf.c | 22 +++---
4 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 0d094da..b8632e9 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -3343,7 +3343,7 @@ static int kvm_arch_setup_async_pf(struct kvm_vcpu
*vcpu, gva_t gva, gfn_t gfn)
arch.direct_map = vcpu-arch.mmu.direct_map;
arch.cr3 = vcpu-arch.mmu.get_cr3(vcpu);
- return kvm_setup_async_pf(vcpu, gva, gfn, arch);
+ return kvm_setup_async_pf(vcpu, gva, gfn_to_hva(vcpu-kvm, gfn), arch);
}
static bool can_do_async_pf(struct kvm_vcpu *vcpu)
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 210f493..969d575 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -175,7 +175,7 @@ struct kvm_async_pf {
void kvm_clear_async_pf_completion_queue(struct kvm_vcpu *vcpu);
void kvm_check_async_pf_completion(struct kvm_vcpu *vcpu);
-int kvm_setup_async_pf(struct kvm_vcpu *vcpu, gva_t gva, gfn_t gfn,
+int kvm_setup_async_pf(struct kvm_vcpu *vcpu, gva_t gva, unsigned long hva,
struct kvm_arch_async_pf *arch);
int kvm_async_pf_wakeup_all(struct kvm_vcpu *vcpu);
#endif
diff --git a/virt/kvm/Kconfig b/virt/kvm/Kconfig
index 779262f..715e6b5 100644
--- a/virt/kvm/Kconfig
+++ b/virt/kvm/Kconfig
@@ -22,6 +22,10 @@ config KVM_MMIO
config KVM_ASYNC_PF
bool
+# Toggle to switch between direct notification and batch job
+config KVM_ASYNC_PF_DIRECT
+ bool
+
config HAVE_KVM_MSI
bool
diff --git a/virt/kvm/async_pf.c b/virt/kvm/async_pf.c
index ea475cd..b8df37a 100644
--- a/virt/kvm/async_pf.c
+++ b/virt/kvm/async_pf.c
@@ -28,6 +28,21 @@
#include async_pf.h
#include trace/events/kvm.h
+static inline void kvm_async_page_direct_present(struct kvm_vcpu *vcpu,
+ struct kvm_async_pf *work)
+{
+#ifdef CONFIG_KVM_ASYNC_PF_DIRECT
+ kvm_arch_async_page_present(vcpu, work);
+#endif
+}
+static inline void kvm_async_page_batch_present(struct kvm_vcpu *vcpu,
+ struct kvm_async_pf *work)
+{
+#ifndef CONFIG_KVM_ASYNC_PF_DIRECT
+ kvm_arch_async_page_present(vcpu, work);
+#endif
+}
+
I would call them kvm_async_page_present_(async|sync)().
Hmm, to much sync in each function name, but I still think it is
better.
static struct kmem_cache *async_pf_cache;
int kvm_async_pf_init(void)
@@ -70,6 +85,7 @@ static void async_pf_execute(struct work_struct *work)
down_read(mm-mmap_sem);
get_user_pages(current, mm, addr, 1, 1, 0, page, NULL);
up_read(mm-mmap_sem);
+ kvm_async_page_direct_present(vcpu, apf);
unuse_mm(mm);
spin_lock(vcpu-async_pf.lock);
@@ -134,7 +150,7 @@ void kvm_check_async_pf_completion(struct kvm_vcpu *vcpu)
if (work-page)
kvm_arch_async_page_ready(vcpu, work);
- kvm_arch_async_page_present(vcpu, work);
+ kvm_async_page_batch_present(vcpu, work);
list_del(work-queue);
vcpu-async_pf.queued--;
@@ -144,7 +160,7 @@ void kvm_check_async_pf_completion(struct kvm_vcpu *vcpu)
}
}
-int kvm_setup_async_pf(struct kvm_vcpu *vcpu, gva_t gva, gfn_t gfn,
+int kvm_setup_async_pf(struct kvm_vcpu *vcpu, gva_t gva, unsigned long hva,
struct kvm_arch_async_pf *arch)
{
struct kvm_async_pf *work;
@@ -166,7 +182,7 @@ int kvm_setup_async_pf(struct kvm_vcpu *vcpu, gva_t gva,
gfn_t gfn,
work-done = false;
work-vcpu = vcpu;
work-gva = gva;
- work-addr = gfn_to_hva(vcpu-kvm, gfn);
+ work-addr = hva;
work-arch = *arch;
work-mm = current-mm;
atomic_inc(work-mm-mm_count);
--
1.8.2.2
--
Gleb.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
