Re: [PATCH] KVM: x86: reset RVI upon system reset

2014-12-15 Thread Paolo Bonzini


On 15/12/2014 02:52, Zhang Haoyu wrote:
 Yes, I find it,
 but what's the relationship between 
 https://git.kernel.org/cgit/virt/kvm/kvm.git/log/?h=next

This is branch next.

 and 
 https://git.kernel.org/cgit/virt/kvm/kvm.git/log/  ?

This is branch master.

Paolo
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] KVM: x86: reset RVI upon system reset

2014-12-14 Thread Zhang Haoyu
On 2014-12-12 18:27:14, Paolo Bonzini wrote:


On 12/12/2014 10:56, Zhang Haoyu wrote:
 Strange, I didn't find this commit in 
 https://git.kernel.org/cgit/virt/kvm/kvm.git/log/
 but found it from the repository downloaded by git clone  
 git://git.kernel.org/pub/scm/virt/kvm/kvm.git

It's here:

https://git.kernel.org/cgit/virt/kvm/kvm.git/log/?h=next

(on the second page)

Yes, I find it,
but what's the relationship between 
https://git.kernel.org/cgit/virt/kvm/kvm.git/log/?h=next
and 
https://git.kernel.org/cgit/virt/kvm/kvm.git/log/  ?
e.g., 
https://git.kernel.org/cgit/virt/kvm/kvm.git/log/?h=nextofs=50
https://git.kernel.org/cgit/virt/kvm/kvm.git/log/?ofs=50

Thanks,
Zhang Haoyu
Paolo

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCH] KVM: x86: reset RVI upon system reset

2014-12-12 Thread Zhang Haoyu
On 2014-12-11 19:06:33, Zhang, Yang Z wrote:
Zhang Haoyu wrote on 2014-12-11:
 Then?

It's already in upstream KVM

Strange, I didn't find this commit in 
https://git.kernel.org/cgit/virt/kvm/kvm.git/log/
but found it from the repository downloaded by git clone  
git://git.kernel.org/pub/scm/virt/kvm/kvm.git

Thanks,
Zhang Haoyu

commit 4114c27d450bef228be9c7b0c40a888e18a3a636
Author: Wei Wang wei.w.w...@intel.com
Date:   Wed Nov 5 10:53:43 2014 +0800

KVM: x86: reset RVI upon system reset

A bug was reported as follows: when running Windows 7 32-bit guests on 
 qemu-kvm,
sometimes the guests run into blue screen during reboot. The problem was 
 that a
guest's RVI was not cleared when it rebooted. This patch has fixed the 
 problem.

Signed-off-by: Wei Wang wei.w.w...@intel.com
Signed-off-by: Yang Zhang yang.z.zh...@intel.com
Tested-by: Rongrong Liu rongrongx@intel.com, Da Chun ng...@qq.com
Signed-off-by: Paolo Bonzini pbonz...@redhat.com


 
 On 05/11/2014 10:02, Chen, Tiejun wrote:
 I think both are ok.
 If we zero max_irr in vmx_set_rvi(), we still need this check:
 if ((is_guest_mode(vcpu)  nested_exit_on_intr(vcpu)) || max_irr
 ==
 -1)
 
 No, I don't think we need to add this.
 
 You don't, because the code will look like:
 
 if (is_guest_mode(vcpu)  nested_exit_on_intr(vcpu))
 return; if (!is_guest_mode(vcpu)) {
 vmx_set_rvi(max_irr); return;
 }
 
 if (max_irr == -1)
 return;
 and thus vmx_set_rvi() is never reached if is_guest_mode(vcpu) 
 !nested_exit_on_intr(vcpu).
 
 I don't think the above code is perfect. Since hwapic_irr_update() is
 a hot point,
 it's better to move the first check after the second check. In this
 case, Wei's patch looks more reasonable.
 
 
 I applied the lapic.c part of Wei's patch, and the vmx.c part of Tiejun's 
 patch.
 
 Paolo
 
 
 Best regards,


Best regards,
Yang

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] KVM: x86: reset RVI upon system reset

2014-12-12 Thread Paolo Bonzini


On 12/12/2014 10:56, Zhang Haoyu wrote:
 Strange, I didn't find this commit in 
 https://git.kernel.org/cgit/virt/kvm/kvm.git/log/
 but found it from the repository downloaded by git clone  
 git://git.kernel.org/pub/scm/virt/kvm/kvm.git

It's here:

https://git.kernel.org/cgit/virt/kvm/kvm.git/log/?h=next

(on the second page)

Paolo
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCH] KVM: x86: reset RVI upon system reset

2014-12-11 Thread Zhang Haoyu
Then?

 On 05/11/2014 10:02, Chen, Tiejun wrote:
 I think both are ok.
 If we zero max_irr in vmx_set_rvi(), we still need this check:
 if ((is_guest_mode(vcpu)  nested_exit_on_intr(vcpu)) || max_irr
 ==
 -1)
 
 No, I don't think we need to add this.
 
 You don't, because the code will look like:
 
 if (is_guest_mode(vcpu)  nested_exit_on_intr(vcpu))
 return;
 if (!is_guest_mode(vcpu)) {
 vmx_set_rvi(max_irr);
 return;
 }
 
 if (max_irr == -1)
 return;
 and thus vmx_set_rvi() is never reached if is_guest_mode(vcpu) 
 !nested_exit_on_intr(vcpu).

I don't think the above code is perfect. Since hwapic_irr_update() is a hot 
point, it's better to move the first check after the second check. In this 
case, Wei's patch looks more reasonable.

 
 I applied the lapic.c part of Wei's patch, and the vmx.c part of Tiejun's 
 patch.
 
 Paolo


Best regards,

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCH] KVM: x86: reset RVI upon system reset

2014-12-11 Thread Zhang, Yang Z
Zhang Haoyu wrote on 2014-12-11:
 Then?

It's already in upstream KVM

commit 4114c27d450bef228be9c7b0c40a888e18a3a636
Author: Wei Wang wei.w.w...@intel.com
Date:   Wed Nov 5 10:53:43 2014 +0800

KVM: x86: reset RVI upon system reset

A bug was reported as follows: when running Windows 7 32-bit guests on 
qemu-kvm,
sometimes the guests run into blue screen during reboot. The problem was 
that a
guest's RVI was not cleared when it rebooted. This patch has fixed the 
problem.

Signed-off-by: Wei Wang wei.w.w...@intel.com
Signed-off-by: Yang Zhang yang.z.zh...@intel.com
Tested-by: Rongrong Liu rongrongx@intel.com, Da Chun ng...@qq.com
Signed-off-by: Paolo Bonzini pbonz...@redhat.com


 
 On 05/11/2014 10:02, Chen, Tiejun wrote:
 I think both are ok.
 If we zero max_irr in vmx_set_rvi(), we still need this check:
 if ((is_guest_mode(vcpu)  nested_exit_on_intr(vcpu)) || max_irr
 ==
 -1)
 
 No, I don't think we need to add this.
 
 You don't, because the code will look like:
 
 if (is_guest_mode(vcpu)  nested_exit_on_intr(vcpu))
 return; if (!is_guest_mode(vcpu)) {
 vmx_set_rvi(max_irr); return;
 }
 
 if (max_irr == -1)
 return;
 and thus vmx_set_rvi() is never reached if is_guest_mode(vcpu) 
 !nested_exit_on_intr(vcpu).
 
 I don't think the above code is perfect. Since hwapic_irr_update() is
 a hot point,
 it's better to move the first check after the second check. In this
 case, Wei's patch looks more reasonable.
 
 
 I applied the lapic.c part of Wei's patch, and the vmx.c part of Tiejun's 
 patch.
 
 Paolo
 
 
 Best regards,


Best regards,
Yang

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] KVM: x86: reset RVI upon system reset

2014-12-11 Thread Paolo Bonzini


On 11/12/2014 09:15, Zhang Haoyu wrote:
  if (is_guest_mode(vcpu)  nested_exit_on_intr(vcpu))
  return;
  if (!is_guest_mode(vcpu)) {
  vmx_set_rvi(max_irr);
  return;
  }
  
  if (max_irr == -1)
  return;
  and thus vmx_set_rvi() is never reached if is_guest_mode(vcpu) 
  !nested_exit_on_intr(vcpu).

I don't think the above code is perfect. Since hwapic_irr_update() is a hot 
point, it's better to move the first check after the second check. In this 
case, Wei's patch looks more

The behavior for max_irr == -1 is different for is_guest_mode(vcpu)
(write 0 to RVI) and !is_guest_mode(vcpu) (do nothing).  So you have to
check is_guest_mode first, as in the patch that was applied.

Paolo
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] KVM: x86: reset RVI upon system reset

2014-11-05 Thread Chen, Tiejun

On 2014/11/5 15:39, Wang, Wei W wrote:

On 05/11/2014 2:14, Tiejun Chen wrote:

A bug was reported as follows: when running Windows 7 32-bit guests on
qemu-kvm, sometimes the guests run into blue screen during reboot. The
problem was that a guest's RVI was not cleared when it rebooted. This

patch has fixed the problem.


Signed-off-by: Wei Wang wei.w.w...@intel.com
Signed-off-by: Yang Zhang yang.z.zh...@intel.com
Tested-by: Rongrong Liu rongrongx@intel.com, Da Chun
ng...@qq.com
---
   arch/x86/kvm/lapic.c |3 +++
   arch/x86/kvm/vmx.c   |   12 ++--
   2 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c index
66dd173..6942742 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -1712,6 +1712,9 @@ void kvm_apic_post_state_restore(struct

kvm_vcpu *vcpu,

apic-isr_count = kvm_apic_vid_enabled(vcpu-kvm) ?
1 : count_vectors(apic-regs + APIC_ISR);
apic-highest_isr_cache = -1;
+   if (kvm_x86_ops-hwapic_irr_update)
+   kvm_x86_ops-hwapic_irr_update(vcpu,
+   apic_find_highest_irr(apic));


Could we pass 0 directly? Because looks we just need to clear RVI.

kvm_x86_ops-hwapic_irr_update(vcpu, 0);

I think this already makes sense based on your description.

Thanks
Tiejun


No. This is a restore function, and we cannot assume that the callers always 
need to reset to the initial state.


Okay. Maybe I'm confused by the following change.



Wei



kvm_x86_ops-hwapic_isr_update(vcpu-kvm,

apic_find_highest_isr(apic));

kvm_make_request(KVM_REQ_EVENT, vcpu);
kvm_rtc_eoi_tracking_restore_one(vcpu);
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index
fe4d2f4..d632548 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -7292,19 +7292,19 @@ static void vmx_set_rvi(int vector)
   static void vmx_hwapic_irr_update(struct kvm_vcpu *vcpu, int max_irr)
   {
if (max_irr == -1)
+   max_irr = 0;
+
+   if (!is_guest_mode(vcpu)) {
+   vmx_set_rvi(max_irr);
return;
+   }

/*
 * If a vmexit is needed, vmx_check_nested_events handles it.
 */
-   if (is_guest_mode(vcpu)  nested_exit_on_intr(vcpu))
+   if ((is_guest_mode(vcpu)  nested_exit_on_intr(vcpu)) || max_irr

==

+0)


Its really not readable to modify max_irr as 0 and check that here, and 
especially when you read the original comment.


So what about this?

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 0cd99d8..bc4558b 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -7280,6 +7280,9 @@ static void vmx_set_rvi(int vector)
u16 status;
u8 old;

+   if (vector == -1)
+   vector = 0;
+
status = vmcs_read16(GUEST_INTR_STATUS);
old = (u8)status  0xff;
if ((u8)vector != old) {
@@ -7291,9 +7294,6 @@ static void vmx_set_rvi(int vector)

 static void vmx_hwapic_irr_update(struct kvm_vcpu *vcpu, int max_irr)
 {
-   if (max_irr == -1)
-   return;
-
/*
 * If a vmexit is needed, vmx_check_nested_events handles it.
 */
@@ -7305,6 +7305,9 @@ static void vmx_hwapic_irr_update(struct kvm_vcpu 
*vcpu, int max_irr)

return;
}

+   if (max_irr == -1)
+   return;
+
/*
 * Fall back to pre-APICv interrupt injection since L2
 * is run without virtual interrupt delivery.


Thanks
Tiejun


return;

-   if (!is_guest_mode(vcpu)) {
-   vmx_set_rvi(max_irr);
-   return;
-   }
-
/*
 * Fall back to pre-APICv interrupt injection since L2
 * is run without virtual interrupt delivery.





--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCH] KVM: x86: reset RVI upon system reset

2014-11-05 Thread Wang, Wei W
On 05/11/2014 4:07, Tiejun Chen wrote:
  A bug was reported as follows: when running Windows 7 32-bit guests
  on qemu-kvm, sometimes the guests run into blue screen during
  reboot. The problem was that a guest's RVI was not cleared when it
  rebooted. This
  patch has fixed the problem.
 
  Signed-off-by: Wei Wang wei.w.w...@intel.com
  Signed-off-by: Yang Zhang yang.z.zh...@intel.com
  Tested-by: Rongrong Liu rongrongx@intel.com, Da Chun
  ng...@qq.com
  ---
 arch/x86/kvm/lapic.c |3 +++
 arch/x86/kvm/vmx.c   |   12 ++--
 2 files changed, 9 insertions(+), 6 deletions(-)
 
  diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c index
  66dd173..6942742 100644
  --- a/arch/x86/kvm/lapic.c
  +++ b/arch/x86/kvm/lapic.c
  @@ -1712,6 +1712,9 @@ void kvm_apic_post_state_restore(struct
  kvm_vcpu *vcpu,
apic-isr_count = kvm_apic_vid_enabled(vcpu-kvm) ?
1 : count_vectors(apic-regs + 
  APIC_ISR);
apic-highest_isr_cache = -1;
  + if (kvm_x86_ops-hwapic_irr_update)
  + kvm_x86_ops-hwapic_irr_update(vcpu,
  + apic_find_highest_irr(apic));
 
  Could we pass 0 directly? Because looks we just need to clear RVI.
 
  kvm_x86_ops-hwapic_irr_update(vcpu, 0);
 
  I think this already makes sense based on your description.
 
  Thanks
  Tiejun
 
  No. This is a restore function, and we cannot assume that the callers
 always need to reset to the initial state.
 
 Okay. Maybe I'm confused by the following change.
 
 
  Wei
 
kvm_x86_ops-hwapic_isr_update(vcpu-kvm,
  apic_find_highest_isr(apic));
kvm_make_request(KVM_REQ_EVENT, vcpu);
kvm_rtc_eoi_tracking_restore_one(vcpu);
  diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index
  fe4d2f4..d632548 100644
  --- a/arch/x86/kvm/vmx.c
  +++ b/arch/x86/kvm/vmx.c
  @@ -7292,19 +7292,19 @@ static void vmx_set_rvi(int vector)
 static void vmx_hwapic_irr_update(struct kvm_vcpu *vcpu, int max_irr)
 {
if (max_irr == -1)
  + max_irr = 0;
  +
  + if (!is_guest_mode(vcpu)) {
  + vmx_set_rvi(max_irr);
return;
  + }
 
/*
 * If a vmexit is needed, vmx_check_nested_events handles it.
 */
  - if (is_guest_mode(vcpu)  nested_exit_on_intr(vcpu))
  + if ((is_guest_mode(vcpu)  nested_exit_on_intr(vcpu)) || max_irr
  ==
  +0)
 
 Its really not readable to modify max_irr as 0 and check that here, and
 especially when you read the original comment.
 
 So what about this?


I think both are ok.
If we zero max_irr in vmx_set_rvi(), we still need this check:
if ((is_guest_mode(vcpu)  nested_exit_on_intr(vcpu)) || max_irr == -1)

Let's see if Paolo has any comments, then send out a second version.

Wei
 
 diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index
 0cd99d8..bc4558b 100644
 --- a/arch/x86/kvm/vmx.c
 +++ b/arch/x86/kvm/vmx.c
 @@ -7280,6 +7280,9 @@ static void vmx_set_rvi(int vector)
  u16 status;
  u8 old;
 
 +   if (vector == -1)
 +   vector = 0;
 +
  status = vmcs_read16(GUEST_INTR_STATUS);
  old = (u8)status  0xff;
  if ((u8)vector != old) {
 @@ -7291,9 +7294,6 @@ static void vmx_set_rvi(int vector)
 
   static void vmx_hwapic_irr_update(struct kvm_vcpu *vcpu, int max_irr)
   {
 -   if (max_irr == -1)
 -   return;
 -
  /*
   * If a vmexit is needed, vmx_check_nested_events handles it.
   */
 @@ -7305,6 +7305,9 @@ static void vmx_hwapic_irr_update(struct
 kvm_vcpu *vcpu, int max_irr)
  return;
  }
 
 +   if (max_irr == -1)
 +   return;
 +
  /*
   * Fall back to pre-APICv interrupt injection since L2
   * is run without virtual interrupt delivery.
 
 
 Thanks
 Tiejun
 
return;
 
  - if (!is_guest_mode(vcpu)) {
  - vmx_set_rvi(max_irr);
  - return;
  - }
  -
/*
 * Fall back to pre-APICv interrupt injection since L2
 * is run without virtual interrupt delivery.
 
 
 
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] KVM: x86: reset RVI upon system reset

2014-11-05 Thread Chen, Tiejun

On 2014/11/5 16:50, Wang, Wei W wrote:

On 05/11/2014 4:07, Tiejun Chen wrote:

A bug was reported as follows: when running Windows 7 32-bit guests
on qemu-kvm, sometimes the guests run into blue screen during
reboot. The problem was that a guest's RVI was not cleared when it
rebooted. This

patch has fixed the problem.


Signed-off-by: Wei Wang wei.w.w...@intel.com
Signed-off-by: Yang Zhang yang.z.zh...@intel.com
Tested-by: Rongrong Liu rongrongx@intel.com, Da Chun
ng...@qq.com
---
arch/x86/kvm/lapic.c |3 +++
arch/x86/kvm/vmx.c   |   12 ++--
2 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c index
66dd173..6942742 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -1712,6 +1712,9 @@ void kvm_apic_post_state_restore(struct

kvm_vcpu *vcpu,

apic-isr_count = kvm_apic_vid_enabled(vcpu-kvm) ?
1 : count_vectors(apic-regs + APIC_ISR);
apic-highest_isr_cache = -1;
+   if (kvm_x86_ops-hwapic_irr_update)
+   kvm_x86_ops-hwapic_irr_update(vcpu,
+   apic_find_highest_irr(apic));


Could we pass 0 directly? Because looks we just need to clear RVI.

kvm_x86_ops-hwapic_irr_update(vcpu, 0);

I think this already makes sense based on your description.

Thanks
Tiejun


No. This is a restore function, and we cannot assume that the callers

always need to reset to the initial state.

Okay. Maybe I'm confused by the following change.



Wei



kvm_x86_ops-hwapic_isr_update(vcpu-kvm,

apic_find_highest_isr(apic));

kvm_make_request(KVM_REQ_EVENT, vcpu);
kvm_rtc_eoi_tracking_restore_one(vcpu);
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index
fe4d2f4..d632548 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -7292,19 +7292,19 @@ static void vmx_set_rvi(int vector)
static void vmx_hwapic_irr_update(struct kvm_vcpu *vcpu, int max_irr)
{
if (max_irr == -1)
+   max_irr = 0;
+
+   if (!is_guest_mode(vcpu)) {
+   vmx_set_rvi(max_irr);
return;
+   }

/*
 * If a vmexit is needed, vmx_check_nested_events handles it.
 */
-   if (is_guest_mode(vcpu)  nested_exit_on_intr(vcpu))
+   if ((is_guest_mode(vcpu)  nested_exit_on_intr(vcpu)) || max_irr

==

+0)


Its really not readable to modify max_irr as 0 and check that here, and
especially when you read the original comment.

So what about this?



I think both are ok.
If we zero max_irr in vmx_set_rvi(), we still need this check:
if ((is_guest_mode(vcpu)  nested_exit_on_intr(vcpu)) || max_irr == -1)


No, I don't think we need to add this.



Let's see if Paolo has any comments, then send out a second version.

Wei


diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index
0cd99d8..bc4558b 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -7280,6 +7280,9 @@ static void vmx_set_rvi(int vector)
  u16 status;
  u8 old;

+   if (vector == -1)
+   vector = 0;
+
  status = vmcs_read16(GUEST_INTR_STATUS);
  old = (u8)status  0xff;
  if ((u8)vector != old) {
@@ -7291,9 +7294,6 @@ static void vmx_set_rvi(int vector)

   static void vmx_hwapic_irr_update(struct kvm_vcpu *vcpu, int max_irr)
   {
-   if (max_irr == -1)
-   return;
-
  /*
   * If a vmexit is needed, vmx_check_nested_events handles it.
   */
@@ -7305,6 +7305,9 @@ static void vmx_hwapic_irr_update(struct
kvm_vcpu *vcpu, int max_irr)
  return;
  }

+   if (max_irr == -1)
+   return;
+


Did you see this?

Tiejun


  /*
   * Fall back to pre-APICv interrupt injection since L2
   * is run without virtual interrupt delivery.


Thanks
Tiejun


return;

-   if (!is_guest_mode(vcpu)) {
-   vmx_set_rvi(max_irr);
-   return;
-   }
-
/*
 * Fall back to pre-APICv interrupt injection since L2
 * is run without virtual interrupt delivery.








--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] KVM: x86: reset RVI upon system reset

2014-11-05 Thread Paolo Bonzini


On 05/11/2014 10:02, Chen, Tiejun wrote:
 I think both are ok.
 If we zero max_irr in vmx_set_rvi(), we still need this check:
 if ((is_guest_mode(vcpu)  nested_exit_on_intr(vcpu)) || max_irr == -1)
 
 No, I don't think we need to add this.

You don't, because the code will look like:

if (is_guest_mode(vcpu)  nested_exit_on_intr(vcpu))
return;

if (!is_guest_mode(vcpu)) {
vmx_set_rvi(max_irr);
return;
}

if (max_irr == -1)
return;

and thus vmx_set_rvi() is never reached if is_guest_mode(vcpu) 
!nested_exit_on_intr(vcpu).

I applied the lapic.c part of Wei's patch, and the vmx.c part of
Tiejun's patch.

Paolo
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCH] KVM: x86: reset RVI upon system reset

2014-11-05 Thread Zhang, Yang Z
Paolo Bonzini wrote on 2014-11-05:
 
 
 On 05/11/2014 10:02, Chen, Tiejun wrote:
 I think both are ok.
 If we zero max_irr in vmx_set_rvi(), we still need this check:
 if ((is_guest_mode(vcpu)  nested_exit_on_intr(vcpu)) || max_irr
 ==
 -1)
 
 No, I don't think we need to add this.
 
 You don't, because the code will look like:
 
 if (is_guest_mode(vcpu)  nested_exit_on_intr(vcpu))
 return;
 if (!is_guest_mode(vcpu)) {
 vmx_set_rvi(max_irr);
 return;
 }
 
 if (max_irr == -1)
 return;
 and thus vmx_set_rvi() is never reached if is_guest_mode(vcpu) 
 !nested_exit_on_intr(vcpu).

I don't think the above code is perfect. Since hwapic_irr_update() is a hot 
point, it's better to move the first check after the second check. In this 
case, Wei's patch looks more reasonable.

 
 I applied the lapic.c part of Wei's patch, and the vmx.c part of Tiejun's 
 patch.
 
 Paolo


Best regards,
Yang

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] KVM: x86: reset RVI upon system reset

2014-11-04 Thread Chen, Tiejun

On 2014/11/5 10:53, Wei Wang wrote:

A bug was reported as follows: when running Windows 7 32-bit guests on qemu-kvm,
sometimes the guests run into blue screen during reboot. The problem was that a
guest's RVI was not cleared when it rebooted. This patch has fixed the problem.

Signed-off-by: Wei Wang wei.w.w...@intel.com
Signed-off-by: Yang Zhang yang.z.zh...@intel.com
Tested-by: Rongrong Liu rongrongx@intel.com, Da Chun ng...@qq.com
---
  arch/x86/kvm/lapic.c |3 +++
  arch/x86/kvm/vmx.c   |   12 ++--
  2 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 66dd173..6942742 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -1712,6 +1712,9 @@ void kvm_apic_post_state_restore(struct kvm_vcpu *vcpu,
apic-isr_count = kvm_apic_vid_enabled(vcpu-kvm) ?
1 : count_vectors(apic-regs + APIC_ISR);
apic-highest_isr_cache = -1;
+   if (kvm_x86_ops-hwapic_irr_update)
+   kvm_x86_ops-hwapic_irr_update(vcpu,
+   apic_find_highest_irr(apic));


Could we pass 0 directly? Because looks we just need to clear RVI.

kvm_x86_ops-hwapic_irr_update(vcpu, 0);

I think this already makes sense based on your description.

Thanks
Tiejun


kvm_x86_ops-hwapic_isr_update(vcpu-kvm, apic_find_highest_isr(apic));
kvm_make_request(KVM_REQ_EVENT, vcpu);
kvm_rtc_eoi_tracking_restore_one(vcpu);
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index fe4d2f4..d632548 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -7292,19 +7292,19 @@ static void vmx_set_rvi(int vector)
  static void vmx_hwapic_irr_update(struct kvm_vcpu *vcpu, int max_irr)
  {
if (max_irr == -1)
+   max_irr = 0;
+
+   if (!is_guest_mode(vcpu)) {
+   vmx_set_rvi(max_irr);
return;
+   }

/*
 * If a vmexit is needed, vmx_check_nested_events handles it.
 */
-   if (is_guest_mode(vcpu)  nested_exit_on_intr(vcpu))
+   if ((is_guest_mode(vcpu)  nested_exit_on_intr(vcpu)) || max_irr == 0)
return;

-   if (!is_guest_mode(vcpu)) {
-   vmx_set_rvi(max_irr);
-   return;
-   }
-
/*
 * Fall back to pre-APICv interrupt injection since L2
 * is run without virtual interrupt delivery.


--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCH] KVM: x86: reset RVI upon system reset

2014-11-04 Thread Wang, Wei W
On 05/11/2014 2:14, Tiejun Chen wrote:
  A bug was reported as follows: when running Windows 7 32-bit guests on
  qemu-kvm, sometimes the guests run into blue screen during reboot. The
  problem was that a guest's RVI was not cleared when it rebooted. This
 patch has fixed the problem.
 
  Signed-off-by: Wei Wang wei.w.w...@intel.com
  Signed-off-by: Yang Zhang yang.z.zh...@intel.com
  Tested-by: Rongrong Liu rongrongx@intel.com, Da Chun
  ng...@qq.com
  ---
arch/x86/kvm/lapic.c |3 +++
arch/x86/kvm/vmx.c   |   12 ++--
2 files changed, 9 insertions(+), 6 deletions(-)
 
  diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c index
  66dd173..6942742 100644
  --- a/arch/x86/kvm/lapic.c
  +++ b/arch/x86/kvm/lapic.c
  @@ -1712,6 +1712,9 @@ void kvm_apic_post_state_restore(struct
 kvm_vcpu *vcpu,
  apic-isr_count = kvm_apic_vid_enabled(vcpu-kvm) ?
  1 : count_vectors(apic-regs + APIC_ISR);
  apic-highest_isr_cache = -1;
  +   if (kvm_x86_ops-hwapic_irr_update)
  +   kvm_x86_ops-hwapic_irr_update(vcpu,
  +   apic_find_highest_irr(apic));
 
 Could we pass 0 directly? Because looks we just need to clear RVI.
 
 kvm_x86_ops-hwapic_irr_update(vcpu, 0);
 
 I think this already makes sense based on your description.
 
 Thanks
 Tiejun

No. This is a restore function, and we cannot assume that the callers always 
need to reset to the initial state.

Wei
 
  kvm_x86_ops-hwapic_isr_update(vcpu-kvm,
 apic_find_highest_isr(apic));
  kvm_make_request(KVM_REQ_EVENT, vcpu);
  kvm_rtc_eoi_tracking_restore_one(vcpu);
  diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index
  fe4d2f4..d632548 100644
  --- a/arch/x86/kvm/vmx.c
  +++ b/arch/x86/kvm/vmx.c
  @@ -7292,19 +7292,19 @@ static void vmx_set_rvi(int vector)
static void vmx_hwapic_irr_update(struct kvm_vcpu *vcpu, int max_irr)
{
  if (max_irr == -1)
  +   max_irr = 0;
  +
  +   if (!is_guest_mode(vcpu)) {
  +   vmx_set_rvi(max_irr);
  return;
  +   }
 
  /*
   * If a vmexit is needed, vmx_check_nested_events handles it.
   */
  -   if (is_guest_mode(vcpu)  nested_exit_on_intr(vcpu))
  +   if ((is_guest_mode(vcpu)  nested_exit_on_intr(vcpu)) || max_irr
 ==
  +0)
  return;
 
  -   if (!is_guest_mode(vcpu)) {
  -   vmx_set_rvi(max_irr);
  -   return;
  -   }
  -
  /*
   * Fall back to pre-APICv interrupt injection since L2
   * is run without virtual interrupt delivery.
 
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html