From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:52613) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qz0IO-0003zY-QT for qemu-devel@nongnu.org; Thu, 01 Sep 2011 01:58:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qz0IN-0008DU-SH for qemu-devel@nongnu.org; Thu, 01 Sep 2011 01:58:36 -0400 Received: from mx1.redhat.com ([209.132.183.28]:24383) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qz0IN-0008CR-Gn for qemu-devel@nongnu.org; Thu, 01 Sep 2011 01:58:35 -0400 Message-ID: <4E5F1F05.7050704@redhat.com> Date: Thu, 01 Sep 2011 08:58:29 +0300 From: Avi Kivity MIME-Version: 1.0 References: <4E58FC3F.6080809@web.de> <4E5BE7C5.60705@us.ibm.com> <4E5BFF51.9010503@web.de> <4E5C00F0.9070103@redhat.com> <4E5DF096.6070207@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] pc: Clean up PIC-to-APIC IRQ path List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: Lucas Meneghel Rodrigues , Anthony Liguori , Marcelo Tosatti , qemu-devel , Jan Kiszka , Gerd Hoffmann On 08/31/2011 07:59 PM, Blue Swirl wrote: > > > > That makes it impossible to migrate level-triggered irq lines. Or at least, > > the receiver has to remember the state, instead of (or in addition to) the > > sender. > > Both ends probably need to remember the state. That should work > without any multiphase restores and transient suppressors. State should always correspond to real hardware state - a flip flop or capacitor. Input is not state, it is input. > It might be also possible to introduce stateful signal lines which > save and restore their state, then the receiving end could check what > is the current level. However, if you consider that the devices may be > restored in random order, if the IRQ line device happens to be > restored later, the receiver would still get wrong information. Adding > priorities could solve this, but I think stateless IRQs are the only > sane way. I agree that irqs should be stateless, since they don't have any memory associated. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.