From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1N0uUv-0007A2-Vu
	for qemu-devel@nongnu.org; Thu, 22 Oct 2009 06:02:22 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1N0uUq-00078K-J4
	for qemu-devel@nongnu.org; Thu, 22 Oct 2009 06:02:20 -0400
Received: from [199.232.76.173] (port=47137 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1N0uUp-000782-KT
	for qemu-devel@nongnu.org; Thu, 22 Oct 2009 06:02:16 -0400
Received: from mx1.redhat.com ([209.132.183.28]:30032)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <avi@redhat.com>) id 1N0uUp-0006YB-0G
	for qemu-devel@nongnu.org; Thu, 22 Oct 2009 06:02:15 -0400
Message-ID: <4AE02DA1.8090500@redhat.com>
Date: Thu, 22 Oct 2009 12:02:09 +0200
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
References: <1255963059-10298-1-git-send-email-agraf@suse.de>
	<4ADDE7E3.9090601@de.ibm.com> <4AE0210D.9020409@redhat.com>
	<4AE02379.4090603@de.ibm.com>
In-Reply-To: <4AE02379.4090603@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: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Carsten Otte <carsteno@de.ibm.com>
Cc: Carsten Otte <cotte@de.ibm.com>, KVM list <kvm@vger.kernel.org>, Alexander Graf <agraf@suse.de>, qemu-devel <qemu-devel@nongnu.org>, hare@suse.de

On 10/22/2009 11:18 AM, Carsten Otte wrote:
>
>> I'd also appreciate an explanation of what this is all about.
> The processor status word does contain various bits about the CPU's 
> state, such as interrupt mask bits, current address space, and the 
> current instruction address. The status is kept in the in-kernel sie 
> control block data structure and has so far only been mirrored into 
> kvm_run during exit_reason == s390_sieic exits because user space 
> needs to work on it. It was never part of get_regs/set_regs and 
> friends as performance optimization: it's needed on almost every exit, 
> having it in kvm_run saves doing syscalls.
> The gdb stub requires an up-to-date copy at every exit, and therefore 
> the patch moves it out of the union and updates it at all userland exits.

gdb is hardly performance critical.  Is that the only reason for the change?

-- 
error compiling committee.c: too many arguments to function