[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] [PATCH] small adjustment to asm constraints forc/s19400



>From: Jan Beulich
>Sent: 2009年3月31日 17:24
>
>>>> "Lu, Guanqun" <guanqun.lu@xxxxxxxxx> 31.03.09 10:54 >>>
>>[before] (XEN)  EFER: d01<0> STAR: e023e00800000000<0> LSTAR: 
>ffff828c8029b000<0> CSTAR: ffff828c8029b080<0>
>>SYSCALL_MASK: 34700<0> FS_BASE: 0<0> GS_BASE: b7f4a6c0<0> 
>SH_GS_BASE: 0
>>[after] (XEN)  EFER: d01<0> STAR: e023e00800000000<0> LSTAR: 
>ffff828c8029b000<0> CSTAR: ffff828c8029b080<0>
>>SYSCALL_MASK: 34700<0> FS_BASE: 0<0> GS_BASE: b7f4a6c0<0> 
>SH_GS_BASE: 0
>> 
>>They're the same.
>>
>>And aslo I dump GDT, IDT, LDT and TR register and tss struct, 
>there are no difference seen.
>>
>>
>>So can you give some advice some more registers should be dumped?
>
>Assuming this is an Intel box, the guest is certainly using 
>sysenter (which the user mode EIP saved on the stack would 
>also suggest), so you're really after the three SYSENTER MSRs. 
>And indeed - restore_rest_processor_state() seems to only care 
>for the STAR ones.
>

Well, got your point. Those three SYSENTER MSRs are lost after resume.
We'll verify whether this is the only missing parts.  BTW, in our box 32-on
-32 S3 works fine, does that mean SYSENTER/SYSEXIT not used in pure
32bit pv environment, since in Xen 32bit path also misses that important
recovery?

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.