|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] Crash with paravirt-ops 2.6.31.6 kernel
On Mon, 2009-11-23 at 16:31 +0000, Jan Beulich wrote:
> >>> Ian Campbell <Ian.Campbell@xxxxxxxxxx> 23.11.09 16:25 >>>
> >Perhaps simply not returning guest userspace with sysret (as above)
> >makes most sense, a syscall already takes a trap through the hypervisor
> >on both entry and exit so I'm not sure the difference between sysret and
> >iret is going to be noticeable.
>
> But this is not just the return-to-user-space path you're changing, but
> also the hypercall one. You certainly don't want an iret in that case.
Don't the hypercalls already always go via iret?
- testw $TRAP_syscall,4(%rsp)
- jz iret_exit_to_guest
IOW if TRAP_syscall is not set (i.e. this is a hypercall not a syscall)
then exit via iret.
> I wonder though whether it wouldn't be possible to alter the TRAP_syscall
> value (stored when entering the hypervisor) in do_iret(), so that whatever
> do_iret() puts on the stack will be processed by iret.
That would make the VGCF_in_syscall passed to the iret hypercall
meaningless/useless?
>
> >> 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
happens.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|