From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:33013)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <avi@redhat.com>) id 1RAPLA-0001b7-0w
	for qemu-devel@nongnu.org; Sun, 02 Oct 2011 12:56:36 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <avi@redhat.com>) id 1RAPL9-00071R-0W
	for qemu-devel@nongnu.org; Sun, 02 Oct 2011 12:56:35 -0400
Received: from mx1.redhat.com ([209.132.183.28]:64923)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <avi@redhat.com>) id 1RAPL8-00071L-Nz
	for qemu-devel@nongnu.org; Sun, 02 Oct 2011 12:56:34 -0400
Message-ID: <4E8897BA.2060400@redhat.com>
Date: Sun, 02 Oct 2011 18:56:26 +0200
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
References: <cover.1317207666.git.jan.kiszka@siemens.com>
	<bcaf89ca8b39b60707d5d3b3f4fa4d2dbd56ffb6.1317207666.git.jan.kiszka@siemens.com>
	<CAAu8pHv+UfBP7d4q=CnhisSoNRscKLFqfxBQm84fi18Rxkdi+Q@mail.gmail.com>
	<4E838F0B.2010900@web.de>
	<CAAu8pHvrqOy0Pd+f5GyUh4u8w2FsHqi=Tj-ZeWKP2ND5tMvi-A@mail.gmail.com>
	<4E856600.9010703@web.de>
	<CAAu8pHv_bPs4o2orSfjLy0Bgq237wMhJJw1hV+J9_=LjD4NDKw@mail.gmail.com>
	<4E86B793.5090003@web.de>
	<CAAu8pHt3zGodeLMNtOcbgbCi8VWbkiV6wyp2heE0p7yiOdaY7Q@mail.gmail.com>
In-Reply-To: <CAAu8pHt3zGodeLMNtOcbgbCi8VWbkiV6wyp2heE0p7yiOdaY7Q@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH 11/22] i8259: Update IRQ state after reset
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Blue Swirl <blauwirbel@gmail.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>, Jan Kiszka <jan.kiszka@web.de>, qemu-devel <qemu-devel@nongnu.org>

On 10/01/2011 10:31 AM, Blue Swirl wrote:
> Therefore it is incorrect to perform any qemu_irq activities during
> reset (also VM restore like the original example), don't you agree?

It is not incorrect.  Real hardware updates outputs on RESET assertion, 
and real hardware deals with devices entering reset at different times 
(due to signal propagation delay or slow devices).

> If we continued to reset all the devices (call the reset handlers
> multiple times), eventually machine state should stabilize (equivalent
> of real HW with nice long reset pulses), but on QEMU the reset event
> is infinitely short so we have to be more careful.

calling qemu_irq_pulse(reset) simulates a reset signal of any length 
(since nothing happens between the two edges).

> Actually I don't think that even a two-phase reset with qemu_irq or
> Pin activity on the second phase would produce correct results in
> every obscure case. Though this may be detectable since the start
> state would be known.

The output signals have to stabilize before the second edge of the reset 
signal.

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