WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: Bug#544145: [Xen-devel] Crash with paravirt-ops 2.6.31.6 kernel

To: Bastian Blank <waldi@xxxxxxxxxx>
Subject: Re: Bug#544145: [Xen-devel] Crash with paravirt-ops 2.6.31.6 kernel
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Mon, 23 Nov 2009 16:52:26 -0800
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Ian Campbell <Ian.Campbell@xxxxxxxxxx>, "544145@xxxxxxxxxxxxxxx" <544145@xxxxxxxxxxxxxxx>
Delivery-date: Mon, 23 Nov 2009 16:52:50 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20091123172334.GA25056@xxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <28846609.721258484676784.JavaMail.root@xxxxxxxxxxxxxxxxxxxxxx> <20091122095403.GA1496@xxxxxxxxxxxxxxxxxxxxxxx> <1258989935.7590.52.camel@xxxxxxxxxxxxxxxxxxxxxx> <20091123163104.GA23475@xxxxxxxxxxxxxxxxxxxxxxx> <1258994579.7590.78.camel@xxxxxxxxxxxxxxxxxxxxxx> <20091123172334.GA25056@xxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20091014 Fedora/3.0-2.8.b4.fc11 Lightning/1.0pre Thunderbird/3.0b4
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.
>>     
> Well, it is documented this way. If you ignore it, it can work (and does
> in this case) but is undefined behaviour.
>   

Linux freely uses iret to return from syscall for things like fork and
exec.  They are complimentary instructions, but nothing requires them to
be paired.

    J

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