This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Crash with paravirt-ops kernel

>>> Ian Campbell <Ian.Campbell@xxxxxxxxxx> 23.11.09 17:44 >>>
>On Mon, 2009-11-23 at 16:31 +0000, Jan Beulich wrote:
>> >> It does not happen on XenSource 2.6.18 kernel
>> >
>> >I assume that this kernel (perhaps coincidentally) manages to use
>> >FLAT_USER_CS32 for compat mode processes.
>> >
>> >> , or the Debian 2.6.26 kernel.
>> >
>> >This was a forward ported 2.6.18-style kernel so I guess the same reason
>> >as 2.6.18.
>> If your analysis was right, 2.6.18 as well as our forward ported kernels
>> should also be affected (both ia32_sysenter_target and ia32_cstar_target
>> store __USER32_CS to the frame, and return via HYPERVISOR_iret), yet
>> supposedly they don't have the problem (though I can't say why that
>> would be). So perhaps there's some other yet un-described aspect to
>> this, or I'm being confused by something...
>I didn't try any of these kernels myself so I don't really know what

Okay, I think I spotted the relevant difference: 2.6.18 and forward ports
set VGCF_in_syscall only when returning from 64-bit system calls (through
ret_from_sys_call) - 32-bit syscalls (regardless of the entry path taken)
return through int_ret_from_sys_call. 32-bit guest kernels shouldn't be
affected by this, as compat mode returns from the hypervisor
(compat_restore_all_guest) always use iret.


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>