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: Bug#544145: [Xen-devel] Crash with paravirt-ops kernel

To: Bastian Blank <waldi@xxxxxxxxxx>
Subject: Re: Bug#544145: [Xen-devel] Crash with paravirt-ops 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: 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.


Xen-devel mailing list