Hi Keir, Ian, The RHEL4 HVM guest hang issue was actually a side effect of change-set 9699. In the rhel4 guest hang rc.sysinit init-script was calls kmodule program to probe the hardware. The kmodule uses the kudzu library call probeDevices(). For probing the graphics hardware in the vbe_get_mode_info() function, sets up the environment and goes into the vm86 mode to do the int x10 call. For returning back to protected mode it sets up a int 0xff call. At the time of calling the int 0xff the guest process pages were not filled up. And it was causing an infinite loop of vmexits with the IDT_VECTORING_INFO on the int 0xff instruction. The reason for the infinite loop is changeset 9699. With that the guest page fault was always getting overridden by the int 0xff gp fault coming from the IDT_VECTORING_INFO. With the attached patch if VMM is injecting exceptions like page faults or gp faults then IDT_VECTORING_INFO field does not override it, and that breaks the vmexit infinite loop for the rhel4. Signed-Off-By: Nitin A Kamble <nitin.a.kamble@intel.com> Signed-Off-By: Jun Nakajima <jun.nakajima@intel.com> Signed-Off-By: Edwin Zhai <edwin.zhai@intel.com> Diffstat: arch/x86/hvm/vmx/io.c | 23 +++++++++++++++-------- include/asm-x86/hvm/vmx/vmcs.h | 1 + include/asm-x86/hvm/vmx/vmx.h | 1 + 3 files changed, 17 insertions(+), 8 deletions(-) Thanks & Regards, Nitin ------------------------------------------------------------------------ ----------- Open Source Technology Center, Intel Corp _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 5 May 2006, at 04:17, Kamble, Nitin A wrote:> The reason for the infinite loop is changeset 9699. With that > the guest page fault was always getting overridden by the int 0xff gp > fault coming from the IDT_VECTORING_INFO. With the attached patch if > VMM > is injecting exceptions like page faults or gp faults then > IDT_VECTORING_INFO field does not override it, and that breaks the > vmexit infinite loop for the rhel4.Ok, that makes sense thanks. Is it not possible to specify that software interrupts do not cause a VMEXIT? That would seem to avoid the problem totally (as the original ''int 0xff'' wouldn''t vmexit), but it looks like maybe it''s not possible. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir, You are right. There is a 32bit exception bitmap field for the vmexit control. It covers the first 32 interrupts/exceptions such as page faults gp faults, int3, into etc. int instruction interrupts start after that. And the vmexit due to int instructions can not be avoided. Thanks & Regards, Nitin ------------------------------------------------------------------------ ----------- Open Source Technology Center, Intel Corp>-----Original Message----- >From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk] > >Is it not possible to specify that software interrupts do not cause a >VMEXIT? That would seem to avoid the problem totally (as the original >''int 0xff'' wouldn''t vmexit), but it looks like maybe it''s not possible. > > -- Keir_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel