>>> Ian Campbell <ian.campb...@citrix.com> 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. 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. >> 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... Jan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
