[PATCH] Crash VMX when guest NMI.

[PATCH] Crash VMX when guest NMI.

[Li, Xin B]

[-- Attachment #1: Type: text/plain, Size: 215 bytes --]

Crash VMX when guest NMI.
It's meanless to call do_nmi of Xen HV when guest NMI, and acturally
guest NMI can only be injected, is it possible to happen inside guest?

Signed-off-by: Xin Li <xin.b.li@intel.com>

[-- Attachment #2: vmx_nmi.patch --]
[-- Type: application/octet-stream, Size: 439 bytes --]

diff -r 1fcdb3a35db3 xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c	Wed Nov 08 10:48:55 2006 +0000
+++ b/xen/arch/x86/hvm/vmx/vmx.c	Wed Nov 08 10:14:55 2006 +0800
@@ -2198,7 +2199,7 @@ asmlinkage void vmx_vmexit_handler(struc
             break;
         }
         case TRAP_nmi:
-            do_nmi(regs);
+            domain_crash_synchronous();
             break;
         default:
             vmx_reflect_exception(v);

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

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

unmodified_drivers build fails in latest unstable version

[tam00]

*unmodified_drivers build fails in latest unstable version downloaded 
this morning.  Here is the output.  Any suggestions?  *

SLES10x64:/tmp/xen-unstable.hg/unmodified_drivers/linux-2.6 # 
./mkbuildtree Defaulting to this machine's architecture, x86_64, for 
linking.
This may be overridden on the command line (i386,x86_64,ia64).
SLES10x64:/tmp/xen-unstable.hg/unmodified_drivers/linux-2.6 # make -C 
/lib/modules/2.6.16.29-xen/build M=$PWD modules
  LD [M]  
/tmp/xen-unstable.hg/unmodified_drivers/linux-2.6/platform-pci/xen-platform-pci.o
/tmp/xen-unstable.hg/unmodified_drivers/linux-2.6/platform-pci/gnttab.o: 
In function `gnttab_init':
gnttab.c:(.init.text+0x0): multiple definition of `init_module'
/tmp/xen-unstable.hg/unmodified_drivers/linux-2.6/platform-pci/platform-pci.o:platform-pci.c:(.init.text+0x0): 
first defined here
ld: Warning: size of symbol `init_module' changed from 56 in 
/tmp/xen-unstable.hg/unmodified_drivers/linux-2.6/platform-pci/platform-pci.o 
to 82 in 
/tmp/xen-unstable.hg/unmodified_drivers/linux-2.6/platform-pci/gnttab.o
make[2]: *** 
[/tmp/xen-unstable.hg/unmodified_drivers/linux-2.6/platform-pci/xen-platform-pci.o] 
Error 1make[1]: *** 
[/tmp/xen-unstable.hg/unmodified_drivers/linux-2.6/platform-pci] Error 2
make: *** [_module_/tmp/xen-unstable.hg/unmodified_drivers/linux-2.6] 
Error 2
make: Leaving directory `/tmp/xen-unstable.hg/linux-2.6.16.29-xen'
SLES10x64:/tmp/xen-unstable.hg/unmodified_drivers/linux-2.6 #

*Does the overrides.mk look correct?*

# Hack: we need to use the config which was used to build the kernel,
# except that that won't have the right headers etc., so duplicate
# some of the mach-xen infrastructure in here.
#
# (i.e. we need the native config for things like -mregparm, but
# a Xen kernel to find the right headers)
EXTRA_CFLAGS += -DCONFIG_VMX -DCONFIG_VMX_GUEST -DCONFIG_X86_XEN
EXTRA_CFLAGS += -DCONFIG_XEN_SHADOW_MODE -DCONFIG_XEN_SHADOW_TRANSLATE
EXTRA_CFLAGS += -DCONFIG_XEN_BLKDEV_GRANT -DXEN_EVTCHN_MASK_OPS
EXTRA_CFLAGS += -DCONFIG_XEN_NETDEV_GRANT_RX -DCONFIG_XEN_NETDEV_GRANT_TX
EXTRA_CFLAGS += -D__XEN_INTERFACE_VERSION__=0x00030202
EXTRA_CFLAGS += -I$(M)/include -I$(M)/compat-include 
-DHAVE_XEN_PLATFORM_COMPAT_H

Re: unmodified_drivers build fails in latest unstable version

[Steven Smith]

[-- Attachment #1.1: Type: text/plain, Size: 676 bytes --]

> SLES10x64:/tmp/xen-unstable.hg/unmodified_drivers/linux-2.6 # 
> ./mkbuildtree Defaulting to this machine's architecture, x86_64, for 
> linking.
> This may be overridden on the command line (i386,x86_64,ia64).
> SLES10x64:/tmp/xen-unstable.hg/unmodified_drivers/linux-2.6 # make -C 
> /lib/modules/2.6.16.29-xen/build M=$PWD modules
Is 2.6.16.29-xen a native kernel?  The unmodified drivers are intended
to be loaded into non-Xen-aware kernels running in fully-virtualised
HVM domains.  They're unlikely to work if compiled against a Xen aware
kernel, and wouldn't be terribly useful in that case, since the
ordinary drivers do the same thing better.

Steven.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: unmodified_drivers build fails in latest unstable version

[tam00]

Steven,

I was trying to build inside Dom0, which is a Xen aware kernel.  Am I 
supposed to boot back into SusE and build the drivers there?  Perhaps, I
need to build the drivers in the VM itself? 

Also, am I using the proper syntax for the build?  And has the build 
been known to work on an x64 based system?

Thanks for your help.



Steven Smith wrote:
>> SLES10x64:/tmp/xen-unstable.hg/unmodified_drivers/linux-2.6 # 
>> ./mkbuildtree Defaulting to this machine's architecture, x86_64, for 
>> linking.
>> This may be overridden on the command line (i386,x86_64,ia64).
>> SLES10x64:/tmp/xen-unstable.hg/unmodified_drivers/linux-2.6 # make -C 
>> /lib/modules/2.6.16.29-xen/build M=$PWD modules
>>     
> Is 2.6.16.29-xen a native kernel?  The unmodified drivers are intended
> to be loaded into non-Xen-aware kernels running in fully-virtualised
> HVM domains.  They're unlikely to work if compiled against a Xen aware
> kernel, and wouldn't be terribly useful in that case, since the
> ordinary drivers do the same thing better.
>
> Steven.
>   

Re: [PATCH] Crash VMX when guest NMI.

[Keir Fraser]

On 8/11/06 13:13, "Li, Xin B" <xin.b.li@intel.com> wrote:

> Crash VMX when guest NMI.
> It's meanless to call do_nmi of Xen HV when guest NMI, and acturally
> guest NMI can only be injected, is it possible to happen inside guest?
> 
> Signed-off-by: Xin Li <xin.b.li@intel.com>

That path is taken for real NMIs. We shouldn't take it for exceptions on
vector 2 as bit 2 is not set in the exception-intercept bitmap.

However, I'll add a patch to actually check the INTRO_INFO_TYPE_MASK before
calling do_nmi(). Certainly we should only do_nmi() if the type is NMI (2).

 -- Keir