From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 06/17] qemu: Introduce next_cflags Date: Tue, 07 Oct 2008 14:07:02 +0200 Message-ID: <48EB50E6.40507@redhat.com> References: <20081006091415.095241851@mchn012c.ww002.siemens.net> <20081006091416.279639535@mchn012c.ww002.siemens.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org To: Jan Kiszka Return-path: Received: from mx2.redhat.com ([66.187.237.31]:57873 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753179AbYJGMHI (ORCPT ); Tue, 7 Oct 2008 08:07:08 -0400 In-Reply-To: <20081006091416.279639535@mchn012c.ww002.siemens.net> Sender: kvm-owner@vger.kernel.org List-ID: Jan Kiszka wrote: > Introduce next_cflags as part of CPUState. It controls the compile flags > of the next newly generated TB. After use, it will automatically be reset > to zero. This allows the caller to simply set and then forget about it, > e.g. to ensure that the next, and only the next TB will contain just a > single instruction. To avoid that next_cflags hits the wrong TB, > interrupt delivery is suppressed when this field is non-zero. > That's a little unfortunate, in that it affects how the guest runs. I don't see an alternative though. -- error compiling committee.c: too many arguments to function