From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N0uun-00069B-Vo for qemu-devel@nongnu.org; Thu, 22 Oct 2009 06:29:06 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N0uuj-00066Y-27 for qemu-devel@nongnu.org; Thu, 22 Oct 2009 06:29:05 -0400 Received: from [199.232.76.173] (port=58390 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N0uui-00066U-Sg for qemu-devel@nongnu.org; Thu, 22 Oct 2009 06:29:00 -0400 Received: from mx1.redhat.com ([209.132.183.28]:2484) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N0uui-0002H0-8Q for qemu-devel@nongnu.org; Thu, 22 Oct 2009 06:29:00 -0400 Message-ID: <4AE033E2.5090902@redhat.com> Date: Thu, 22 Oct 2009 12:28:50 +0200 From: Avi Kivity MIME-Version: 1.0 References: <1255963059-10298-1-git-send-email-agraf@suse.de> <4ADDE7E3.9090601@de.ibm.com> <4AE0210D.9020409@redhat.com> <98DC9E4C-7FFA-4F05-A2E8-0B5DF546891C@suse.de> <4AE02B8E.6070202@redhat.com> <8D99A5FD-8A2E-4DA9-90A5-6935F677F9FD@suse.de> <4AE02DE2.7010803@redhat.com> <4AE0327D.7010809@de.ibm.com> In-Reply-To: <4AE0327D.7010809@de.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 0/9] S390x KVM support List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Carsten Otte Cc: Carsten Otte , KVM list , Alexander Graf , qemu-devel , hare@suse.de On 10/22/2009 12:22 PM, Carsten Otte wrote: > Avi Kivity wrote: >> Right, but why? x86 qemu doesn't care about either pc or eflags >> (with in-kernel irqchip, which s390 essentially is). > For different reasons. Most prominent for setting the condition code, > which is a sideband result of most instructions that indicates whether or > not the instruction actually worked - similar to the exception model in > high level programming languages. Ok. Thanks for the explanation. On x86 we avoid emulating instructions in userspace. Instead the kernel requests userspace to do something (triggered by the instruction), and the kernel does anything which might be implied by the instruction (like copying the result into a register, or updating pc). An example is port I/O. instead of userspace reading %edx to query the port number and setting %eax to indicate the result, userspace reads a port number struct field and writes an I/O result struct field. Only the kernel accesses registers. I don't know whether that model makes sense or not for s390, but please consider it. -- error compiling committee.c: too many arguments to function