On Wed, 2009-11-25 at 21:24 +, Jeremy Fitzhardinge wrote:
> On 11/25/09 02:22, Jan Beulich wrote:
> > 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
>>> Jeremy Fitzhardinge 25.11.09 22:24 >>>
>On 11/25/09 02:22, Jan Beulich wrote:
>> 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 ent
On 11/25/09 02:22, Jan Beulich wrote:
> 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
>>> Ian Campbell 23.11.09 17:44 >>>
>On Mon, 2009-11-23 at 16:31 +, 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
On Tue, 2009-11-24 at 00:39 +, Jeremy Fitzhardinge wrote:
> On 11/23/09 07:25, Ian Campbell wrote:
> > On Sun, 2009-11-22 at 09:54 +, Bastian Blank wrote:
> >
> >> On Tue, Nov 17, 2009 at 10:04:36PM +0300, William Pitcock wrote:
> >>
> >>> [1.254927] init[1] general protection i
On 11/23/09 09:23, Bastian Blank wrote:
>> I don't believe that is the case (the processor would have to carry some
>> state for the entire duration of a syscall for it to make any
>> difference). I think the spec simply assumes that an OS author would
>> want to use sysret if they used syscall.
>>
On 11/23/09 07:25, Ian Campbell wrote:
> On Sun, 2009-11-22 at 09:54 +, Bastian Blank wrote:
>
>> On Tue, Nov 17, 2009 at 10:04:36PM +0300, William Pitcock wrote:
>>
>>> [1.254927] init[1] general protection ip:f779042f sp:ff9b0340 error:0
>>>
>> Hmm, this looks like the old
On 23/11/2009 16:44, "Ian Campbell" wrote:
>> 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)
> -j
On Mon, Nov 23, 2009 at 04:42:59PM +, Ian Campbell wrote:
> On Mon, 2009-11-23 at 16:31 +, Bastian Blank wrote:
> > The code actually have to know if it was called from 64 or compatibility
> > mode, not assume it.
> Sounds correct. This is tricky for a hypervisor since we don't know the
> m
On Mon, 2009-11-23 at 17:13 +, Keir Fraser wrote:
> On 23/11/2009 16:44, "Ian Campbell" wrote:
>
> >> 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 alway
>>> Ian Campbell 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
On Mon, 2009-11-23 at 16:31 +, Jan Beulich wrote:
> >>> Ian Campbell 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 bet
On Mon, 2009-11-23 at 16:31 +, Bastian Blank wrote:
> On Mon, Nov 23, 2009 at 03:25:35PM +, Ian Campbell wrote:
> > We are attempting to return to the Linux defined __USER_CS32 (0x23)
> > which does not match the test for the Xen defined FLAT_USER_CS32
> > (0xe023) and therefore we hit the
On Mon, Nov 23, 2009 at 03:25:35PM +, Ian Campbell wrote:
> We are attempting to return to the Linux defined __USER_CS32 (0x23)
> which does not match the test for the Xen defined FLAT_USER_CS32
> (0xe023) and therefore we hit the sysretq instead of the sysretl which
> causes us to return with
On Sun, 2009-11-22 at 09:54 +, Bastian Blank wrote:
> On Tue, Nov 17, 2009 at 10:04:36PM +0300, William Pitcock wrote:
> > [1.254927] init[1] general protection ip:f779042f sp:ff9b0340 error:0
>
> Hmm, this looks like the old Debian bug 544145[1]. For some reason the
> hypervisor jumps bac
15 matches
Mail list logo
