Xen devel - Sep 2005 - [PATCh][VT] do_block upon hlt instruction

This patch fixes a bug where raise_softirq(SCHEDULE_SOFTIRQ) is called
upon a hlt instruction from a VMX guest, causing repeated VMExits when
the guest is idle. At the same time, it disables the monitor/mwait
feature as it''s not feasible to implement for vcpu.

Signed-off-by: Xiaofeng Ling <xiaofeng.ling@intel.com>
Signed-off-by: Asit Mallick <asit.k.mallick@intel.com>
Signed-off-by: Jun Nakajima <jun.nakajima@intel.com>

 arch/x86/vmx.c               |   16 +++++++++++++---
 arch/x86/vmx_intercept.c     |    3 +++
 include/asm-x86/vmx_virpit.h |    4 ++--
3 files changed, 18 insertions(+), 5 deletions(-)

Jun
---
Intel Open Source Technology Center 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Nakajima, Jun wrote:
> This patch fixes a bug where raise_softirq(SCHEDULE_SOFTIRQ) is
> called upon a hlt instruction from a VMX guest, causing repeated
> VMExits when the guest is idle. At the same time, it disables the
> monitor/mwait feature as it''s not feasible to implement for vcpu.
> 
> Signed-off-by: Xiaofeng Ling <xiaofeng.ling@intel.com>
> Signed-off-by: Asit Mallick <asit.k.mallick@intel.com>
> Signed-off-by: Jun Nakajima <jun.nakajima@intel.com>
> 
>  arch/x86/vmx.c               |   16 +++++++++++++---
>  arch/x86/vmx_intercept.c     |    3 +++
>  include/asm-x86/vmx_virpit.h |    4 ++--
> 3 files changed, 18 insertions(+), 5 deletions(-)
> 
> Jun
> ---
> Intel Open Source Technology Center
The patch is attached.


Jun
---
Intel Open Source Technology Center


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 21 Sep 2005, at 17:39, Nakajima, Jun wrote:
> This patch fixes a bug where raise_softirq(SCHEDULE_SOFTIRQ) is called
> upon a hlt instruction from a VMX guest, causing repeated VMExits when
> the guest is idle. At the same time, it disables the monitor/mwait
> feature as it''s not feasible to implement for vcpu.
You forgot to attach the patch.

   -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 21 Sep 2005, at 17:39, Nakajima, Jun wrote:
> At the same time, it disables the monitor/mwait
> feature as it''s not feasible to implement for vcpu.
Why is that?

  -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Keir Fraser wrote:
> On 21 Sep 2005, at 17:39, Nakajima, Jun wrote:
> 
>> At the same time, it disables the monitor/mwait
>> feature as it''s not feasible to implement for vcpu.
> 
> Why is that?
> 
>   -- Keir
The major usage model of MONITOR/MWAIT is, the MONITOR instruction
specifies the address to watch, and MWAIT waits for any modification to
that address:
- The current VMX does not support VMExit upon the MONITOR instrucion,
so 
  we don''t know which address the guest wants to minitor.
- even if it did, it''s not efficient to check if modification is made 
  to that address range in shadow (so that we can unblock the guest from
  MWAIT).

Jun
---
Intel Open Source Technology Center

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 21 Sep 2005, at 18:37, Nakajima, Jun wrote:
> The major usage model of MONITOR/MWAIT is, the MONITOR instruction
> specifies the address to watch, and MWAIT waits for any modification to
> that address:
> - The current VMX does not support VMExit upon the MONITOR instrucion,
> so
>   we don''t know which address the guest wants to minitor.
> - even if it did, it''s not efficient to check if modification is
made
>   to that address range in shadow (so that we can unblock the guest 
> from
>   MWAIT).
Hmm yes, good point. :-)

  -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel