diff mbox

[3/5] kvm: kick vcpu when async_pf is resolved

Message ID 20161202084754.22860-4-rkagan@virtuozzo.com (mailing list archive)
State New, archived
Headers show

Commit Message

Roman Kagan Dec. 2, 2016, 8:47 a.m. UTC
When async_pf is ready the guest needs to be made aware of it ASAP,
because it may be holding off a higher priority task pending the
async_pf resolution in favor of a lower priority one.

In case async_pf's are harvested in vcpu context (x86) we have to not
only wake the vcpu up but kick it into host.

While at this, also replace the open-coded vcpu wakeup by the existing
helper.

Signed-off-by: Roman Kagan <rkagan@virtuozzo.com>
---
 virt/kvm/async_pf.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

Comments

Christian Borntraeger Dec. 2, 2016, 9:35 a.m. UTC | #1
On 12/02/2016 09:47 AM, Roman Kagan wrote:
> When async_pf is ready the guest needs to be made aware of it ASAP,
> because it may be holding off a higher priority task pending the
> async_pf resolution in favor of a lower priority one.
> 
> In case async_pf's are harvested in vcpu context (x86) we have to not
> only wake the vcpu up but kick it into host.
> 
> While at this, also replace the open-coded vcpu wakeup by the existing
> helper.
> 
> Signed-off-by: Roman Kagan <rkagan@virtuozzo.com>
> ---
>  virt/kvm/async_pf.c | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/virt/kvm/async_pf.c b/virt/kvm/async_pf.c
> index 9cced14..5f0a66c 100644
> --- a/virt/kvm/async_pf.c
> +++ b/virt/kvm/async_pf.c
> @@ -105,8 +105,11 @@ static void async_pf_execute(struct work_struct *work)
>  	 * This memory barrier pairs with prepare_to_wait's set_current_state()
>  	 */
>  	smp_mb();
> -	if (swait_active(&vcpu->wq))
> -		swake_up(&vcpu->wq);
> +#ifdef CONFIG_KVM_ASYNC_PF_SYNC
> +	kvm_vcpu_wake_up(vcpu);
> +#else
> +	kvm_vcpu_kick(vcpu);
> +#endif

This will break s390, both functions are disabled for s390.
On s390 do not want to kick the CPU for a completion. Instead we implement
the kvm_async_page_present_sync call above and handle completion via an 
"pfault done" interrupt via the normal interrupt delivery.

> 
>  	mmput(mm);
>  	kvm_put_kvm(vcpu->kvm);
> 

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Paolo Bonzini Dec. 2, 2016, 9:40 a.m. UTC | #2
----- Original Message -----
> From: "Christian Borntraeger" <borntraeger@de.ibm.com>
> To: "Roman Kagan" <rkagan@virtuozzo.com>, "Radim Krčmář" <rkrcmar@redhat.com>, "Paolo Bonzini" <pbonzini@redhat.com>,
> kvm@vger.kernel.org
> Cc: "Denis Lunev" <den@virtuozzo.com>
> Sent: Friday, December 2, 2016 10:35:02 AM
> Subject: Re: [PATCH 3/5] kvm: kick vcpu when async_pf is resolved
> 
> On 12/02/2016 09:47 AM, Roman Kagan wrote:
> > When async_pf is ready the guest needs to be made aware of it ASAP,
> > because it may be holding off a higher priority task pending the
> > async_pf resolution in favor of a lower priority one.
> > 
> > In case async_pf's are harvested in vcpu context (x86) we have to not
> > only wake the vcpu up but kick it into host.
> > 
> > While at this, also replace the open-coded vcpu wakeup by the existing
> > helper.
> > 
> > Signed-off-by: Roman Kagan <rkagan@virtuozzo.com>
> > ---
> >  virt/kvm/async_pf.c | 7 +++++--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> > 
> > diff --git a/virt/kvm/async_pf.c b/virt/kvm/async_pf.c
> > index 9cced14..5f0a66c 100644
> > --- a/virt/kvm/async_pf.c
> > +++ b/virt/kvm/async_pf.c
> > @@ -105,8 +105,11 @@ static void async_pf_execute(struct work_struct *work)
> >  	 * This memory barrier pairs with prepare_to_wait's set_current_state()
> >  	 */
> >  	smp_mb();
> > -	if (swait_active(&vcpu->wq))
> > -		swake_up(&vcpu->wq);
> > +#ifdef CONFIG_KVM_ASYNC_PF_SYNC
> > +	kvm_vcpu_wake_up(vcpu);
> > +#else
> > +	kvm_vcpu_kick(vcpu);
> > +#endif
> 
> This will break s390, both functions are disabled for s390.
> On s390 do not want to kick the CPU for a completion. Instead we implement
> the kvm_async_page_present_sync call above and handle completion via an
> "pfault done" interrupt via the normal interrupt delivery.

Is there any reason (with this patch) to disable kvm_vcpu_wake_up on s390?
It was unused until now, but the patch makes sense as a cleanup.

Paolo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Christian Borntraeger Dec. 2, 2016, 10 a.m. UTC | #3
On 12/02/2016 10:40 AM, Paolo Bonzini wrote:
> 
> 
> ----- Original Message -----
>> From: "Christian Borntraeger" <borntraeger@de.ibm.com>
>> To: "Roman Kagan" <rkagan@virtuozzo.com>, "Radim Krčmář" <rkrcmar@redhat.com>, "Paolo Bonzini" <pbonzini@redhat.com>,
>> kvm@vger.kernel.org
>> Cc: "Denis Lunev" <den@virtuozzo.com>
>> Sent: Friday, December 2, 2016 10:35:02 AM
>> Subject: Re: [PATCH 3/5] kvm: kick vcpu when async_pf is resolved
>>
>> On 12/02/2016 09:47 AM, Roman Kagan wrote:
>>> When async_pf is ready the guest needs to be made aware of it ASAP,
>>> because it may be holding off a higher priority task pending the
>>> async_pf resolution in favor of a lower priority one.
>>>
>>> In case async_pf's are harvested in vcpu context (x86) we have to not
>>> only wake the vcpu up but kick it into host.
>>>
>>> While at this, also replace the open-coded vcpu wakeup by the existing
>>> helper.
>>>
>>> Signed-off-by: Roman Kagan <rkagan@virtuozzo.com>
>>> ---
>>>  virt/kvm/async_pf.c | 7 +++++--
>>>  1 file changed, 5 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/virt/kvm/async_pf.c b/virt/kvm/async_pf.c
>>> index 9cced14..5f0a66c 100644
>>> --- a/virt/kvm/async_pf.c
>>> +++ b/virt/kvm/async_pf.c
>>> @@ -105,8 +105,11 @@ static void async_pf_execute(struct work_struct *work)
>>>  	 * This memory barrier pairs with prepare_to_wait's set_current_state()
>>>  	 */
>>>  	smp_mb();
>>> -	if (swait_active(&vcpu->wq))
>>> -		swake_up(&vcpu->wq);
>>> +#ifdef CONFIG_KVM_ASYNC_PF_SYNC
>>> +	kvm_vcpu_wake_up(vcpu);
>>> +#else
>>> +	kvm_vcpu_kick(vcpu);
>>> +#endif
>>
>> This will break s390, both functions are disabled for s390.
>> On s390 do not want to kick the CPU for a completion. Instead we implement
>> the kvm_async_page_present_sync call above and handle completion via an
>> "pfault done" interrupt via the normal interrupt delivery.
> 
> Is there any reason (with this patch) to disable kvm_vcpu_wake_up on s390?
> It was unused until now, but the patch makes sense as a cleanup.


We could enable that. It was some kind of a trigger, that we get a build error
when someone enables that for s390 (as it might not be want you want)

On the other hand,  I dont think that we need a wakeup at all for the
SYNC case. (as the interrupt will do that anyway)
Maybe something like that

-	if (swait_active(&vcpu->wq))
-		swake_up(&vcpu->wq);
+#ifndef CONFIG_KVM_ASYNC_PF_SYNC
+	kvm_vcpu_kick(vcpu);
+#endif

would be good enough. (needs more thinking to be sure)

Christian

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Roman Kagan Dec. 2, 2016, 11:28 a.m. UTC | #4
On Fri, Dec 02, 2016 at 10:35:02AM +0100, Christian Borntraeger wrote:
> On 12/02/2016 09:47 AM, Roman Kagan wrote:
> > When async_pf is ready the guest needs to be made aware of it ASAP,
> > because it may be holding off a higher priority task pending the
> > async_pf resolution in favor of a lower priority one.
> > 
> > In case async_pf's are harvested in vcpu context (x86) we have to not
> > only wake the vcpu up but kick it into host.
> > 
> > While at this, also replace the open-coded vcpu wakeup by the existing
> > helper.
> > 
> > Signed-off-by: Roman Kagan <rkagan@virtuozzo.com>
> > ---
> >  virt/kvm/async_pf.c | 7 +++++--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> > 
> > diff --git a/virt/kvm/async_pf.c b/virt/kvm/async_pf.c
> > index 9cced14..5f0a66c 100644
> > --- a/virt/kvm/async_pf.c
> > +++ b/virt/kvm/async_pf.c
> > @@ -105,8 +105,11 @@ static void async_pf_execute(struct work_struct *work)
> >  	 * This memory barrier pairs with prepare_to_wait's set_current_state()
> >  	 */
> >  	smp_mb();
> > -	if (swait_active(&vcpu->wq))
> > -		swake_up(&vcpu->wq);
> > +#ifdef CONFIG_KVM_ASYNC_PF_SYNC
> > +	kvm_vcpu_wake_up(vcpu);
> > +#else
> > +	kvm_vcpu_kick(vcpu);
> > +#endif
> 
> This will break s390, both functions are disabled for s390.

Indeed.  Sorry I didn't notice that #ifndef CONFIG_S390 ...

> On s390 do not want to kick the CPU for a completion. Instead we implement
> the kvm_async_page_present_sync call above and handle completion via an 
> "pfault done" interrupt via the normal interrupt delivery.

I wonder if waking up is necessary at all then?

Thanks,
Roman.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Roman Kagan Dec. 2, 2016, 11:34 a.m. UTC | #5
On Fri, Dec 02, 2016 at 11:00:00AM +0100, Christian Borntraeger wrote:
> On 12/02/2016 10:40 AM, Paolo Bonzini wrote:
> > ----- Original Message -----
> >> From: "Christian Borntraeger" <borntraeger@de.ibm.com>
> >> To: "Roman Kagan" <rkagan@virtuozzo.com>, "Radim Krčmář" <rkrcmar@redhat.com>, "Paolo Bonzini" <pbonzini@redhat.com>,
> >> kvm@vger.kernel.org
> >> Cc: "Denis Lunev" <den@virtuozzo.com>
> >> Sent: Friday, December 2, 2016 10:35:02 AM
> >> Subject: Re: [PATCH 3/5] kvm: kick vcpu when async_pf is resolved
> >>
> >> On 12/02/2016 09:47 AM, Roman Kagan wrote:
> >>> When async_pf is ready the guest needs to be made aware of it ASAP,
> >>> because it may be holding off a higher priority task pending the
> >>> async_pf resolution in favor of a lower priority one.
> >>>
> >>> In case async_pf's are harvested in vcpu context (x86) we have to not
> >>> only wake the vcpu up but kick it into host.
> >>>
> >>> While at this, also replace the open-coded vcpu wakeup by the existing
> >>> helper.
> >>>
> >>> Signed-off-by: Roman Kagan <rkagan@virtuozzo.com>
> >>> ---
> >>>  virt/kvm/async_pf.c | 7 +++++--
> >>>  1 file changed, 5 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/virt/kvm/async_pf.c b/virt/kvm/async_pf.c
> >>> index 9cced14..5f0a66c 100644
> >>> --- a/virt/kvm/async_pf.c
> >>> +++ b/virt/kvm/async_pf.c
> >>> @@ -105,8 +105,11 @@ static void async_pf_execute(struct work_struct *work)
> >>>  	 * This memory barrier pairs with prepare_to_wait's set_current_state()
> >>>  	 */
> >>>  	smp_mb();
> >>> -	if (swait_active(&vcpu->wq))
> >>> -		swake_up(&vcpu->wq);
> >>> +#ifdef CONFIG_KVM_ASYNC_PF_SYNC
> >>> +	kvm_vcpu_wake_up(vcpu);
> >>> +#else
> >>> +	kvm_vcpu_kick(vcpu);
> >>> +#endif
> >>
> >> This will break s390, both functions are disabled for s390.
> >> On s390 do not want to kick the CPU for a completion. Instead we implement
> >> the kvm_async_page_present_sync call above and handle completion via an
> >> "pfault done" interrupt via the normal interrupt delivery.
> > 
> > Is there any reason (with this patch) to disable kvm_vcpu_wake_up on s390?
> > It was unused until now, but the patch makes sense as a cleanup.
> 
> 
> We could enable that. It was some kind of a trigger, that we get a build error
> when someone enables that for s390 (as it might not be want you want)
> 
> On the other hand,  I dont think that we need a wakeup at all for the
> SYNC case. (as the interrupt will do that anyway)
> Maybe something like that
> 
> -	if (swait_active(&vcpu->wq))
> -		swake_up(&vcpu->wq);
> +#ifndef CONFIG_KVM_ASYNC_PF_SYNC
> +	kvm_vcpu_kick(vcpu);
> +#endif
> 
> would be good enough. (needs more thinking to be sure)

As my knowlege of s390 approaches zero so that only your thinking can be
applied here ;) , how about me redoing this patch leaving the open-coded
wakeup as is, and then you submitting another patch on top dropping that
wakeup if you find that appropriate?

Thanks,
Roman.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
kernel test robot Dec. 3, 2016, 4:02 a.m. UTC | #6
Hi Roman,

[auto build test ERROR on kvm/linux-next]
[also build test ERROR on v4.9-rc7 next-20161202]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/Roman-Kagan/kvm-avoid-delaying-async_pf-ready-delivery/20161203-081205
base:   https://git.kernel.org/pub/scm/virt/kvm/kvm.git linux-next
config: s390-default_defconfig (attached as .config)
compiler: s390x-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
        wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        make.cross ARCH=s390 

All errors (new ones prefixed by >>):

>> ERROR: "kvm_vcpu_wake_up" [arch/s390/kvm/kvm.ko] undefined!

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
Christian Borntraeger Dec. 5, 2016, 8:08 a.m. UTC | #7
On 12/02/2016 12:34 PM, Roman Kagan wrote:
> On Fri, Dec 02, 2016 at 11:00:00AM +0100, Christian Borntraeger wrote:
>> On 12/02/2016 10:40 AM, Paolo Bonzini wrote:
>>> ----- Original Message -----
>>>> From: "Christian Borntraeger" <borntraeger@de.ibm.com>
>>>> To: "Roman Kagan" <rkagan@virtuozzo.com>, "Radim Krčmář" <rkrcmar@redhat.com>, "Paolo Bonzini" <pbonzini@redhat.com>,
>>>> kvm@vger.kernel.org
>>>> Cc: "Denis Lunev" <den@virtuozzo.com>
>>>> Sent: Friday, December 2, 2016 10:35:02 AM
>>>> Subject: Re: [PATCH 3/5] kvm: kick vcpu when async_pf is resolved
>>>>
>>>> On 12/02/2016 09:47 AM, Roman Kagan wrote:
>>>>> When async_pf is ready the guest needs to be made aware of it ASAP,
>>>>> because it may be holding off a higher priority task pending the
>>>>> async_pf resolution in favor of a lower priority one.
>>>>>
>>>>> In case async_pf's are harvested in vcpu context (x86) we have to not
>>>>> only wake the vcpu up but kick it into host.
>>>>>
>>>>> While at this, also replace the open-coded vcpu wakeup by the existing
>>>>> helper.
>>>>>
>>>>> Signed-off-by: Roman Kagan <rkagan@virtuozzo.com>
>>>>> ---
>>>>>  virt/kvm/async_pf.c | 7 +++++--
>>>>>  1 file changed, 5 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/virt/kvm/async_pf.c b/virt/kvm/async_pf.c
>>>>> index 9cced14..5f0a66c 100644
>>>>> --- a/virt/kvm/async_pf.c
>>>>> +++ b/virt/kvm/async_pf.c
>>>>> @@ -105,8 +105,11 @@ static void async_pf_execute(struct work_struct *work)
>>>>>  	 * This memory barrier pairs with prepare_to_wait's set_current_state()
>>>>>  	 */
>>>>>  	smp_mb();
>>>>> -	if (swait_active(&vcpu->wq))
>>>>> -		swake_up(&vcpu->wq);
>>>>> +#ifdef CONFIG_KVM_ASYNC_PF_SYNC
>>>>> +	kvm_vcpu_wake_up(vcpu);
>>>>> +#else
>>>>> +	kvm_vcpu_kick(vcpu);
>>>>> +#endif
>>>>
>>>> This will break s390, both functions are disabled for s390.
>>>> On s390 do not want to kick the CPU for a completion. Instead we implement
>>>> the kvm_async_page_present_sync call above and handle completion via an
>>>> "pfault done" interrupt via the normal interrupt delivery.
>>>
>>> Is there any reason (with this patch) to disable kvm_vcpu_wake_up on s390?
>>> It was unused until now, but the patch makes sense as a cleanup.
>>
>>
>> We could enable that. It was some kind of a trigger, that we get a build error
>> when someone enables that for s390 (as it might not be want you want)
>>
>> On the other hand,  I dont think that we need a wakeup at all for the
>> SYNC case. (as the interrupt will do that anyway)
>> Maybe something like that
>>
>> -	if (swait_active(&vcpu->wq))
>> -		swake_up(&vcpu->wq);
>> +#ifndef CONFIG_KVM_ASYNC_PF_SYNC
>> +	kvm_vcpu_kick(vcpu);
>> +#endif
>>
>> would be good enough. (needs more thinking to be sure)
> 
> As my knowlege of s390 approaches zero so that only your thinking can be
> applied here ;) , how about me redoing this patch leaving the open-coded
> wakeup as is, and then you submitting another patch on top dropping that
> wakeup if you find that appropriate?

Yes, please do you patch with the swake_up and I will come up with a followup.

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
kernel test robot Dec. 6, 2016, 11:05 a.m. UTC | #8
Hi Roman,

[auto build test ERROR on kvm/linux-next]
[also build test ERROR on v4.9-rc8 next-20161205]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/Roman-Kagan/kvm-avoid-delaying-async_pf-ready-delivery/20161203-081205
base:   https://git.kernel.org/pub/scm/virt/kvm/kvm.git linux-next
config: s390-alldefconfig (attached as .config)
compiler: s390x-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
        wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        make.cross ARCH=s390 

All errors (new ones prefixed by >>):

   arch/s390/built-in.o: In function `async_pf_execute':
>> arch/s390/kvm/../../../virt/kvm/async_pf.o:(.text+0x26cee): undefined reference to `kvm_vcpu_wake_up'

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
diff mbox

Patch

diff --git a/virt/kvm/async_pf.c b/virt/kvm/async_pf.c
index 9cced14..5f0a66c 100644
--- a/virt/kvm/async_pf.c
+++ b/virt/kvm/async_pf.c
@@ -105,8 +105,11 @@  static void async_pf_execute(struct work_struct *work)
 	 * This memory barrier pairs with prepare_to_wait's set_current_state()
 	 */
 	smp_mb();
-	if (swait_active(&vcpu->wq))
-		swake_up(&vcpu->wq);
+#ifdef CONFIG_KVM_ASYNC_PF_SYNC
+	kvm_vcpu_wake_up(vcpu);
+#else
+	kvm_vcpu_kick(vcpu);
+#endif
 
 	mmput(mm);
 	kvm_put_kvm(vcpu->kvm);