From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:48685) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0E0r-0002Tm-6D for qemu-devel@nongnu.org; Sun, 04 Sep 2011 10:49:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R0E0p-0005EN-Vk for qemu-devel@nongnu.org; Sun, 04 Sep 2011 10:49:33 -0400 Received: from mail-gx0-f173.google.com ([209.85.161.173]:57717) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0E0p-0005EI-SX for qemu-devel@nongnu.org; Sun, 04 Sep 2011 10:49:31 -0400 Received: by gxk26 with SMTP id 26so2827234gxk.4 for ; Sun, 04 Sep 2011 07:49:31 -0700 (PDT) Message-ID: <4E638FF9.6010105@codemonkey.ws> Date: Sun, 04 Sep 2011 09:49:29 -0500 From: Anthony Liguori 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> <4E6285BB.2010505@codemonkey.ws> 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 , Marcelo Tosatti , qemu-devel , Jan Kiszka , Avi Kivity , Gerd Hoffmann On 09/03/2011 04:01 PM, Blue Swirl wrote: > On Sat, Sep 3, 2011 at 7:53 PM, Anthony Liguori wrote: >> On 08/31/2011 11:59 AM, Blue Swirl wrote: >>> >>> On Wed, Aug 31, 2011 at 8:28 AM, Avi Kivity wrote: >>>> >>>> On 08/30/2011 10:19 PM, Blue Swirl wrote: >>>>> >>>>>> >>>>>> We need some kind of two phase restore. In the first phase all state >>>>>> is >>>>>> restored; since some of that state drivers outputs that are input to >>>>>> other >>>>>> devices, they may experience an edge, and we need to supress that. In >>>>>> the >>>>>> second phase edge detection is unsupressed and the device goes live. >>>>> >>>>> No. Devices may not perform any externally visible activities (like >>>>> toggle a qemu_irq) during or after load because 1) qemu_irq is >>>>> stateless and 2) since the receiving end is also freshly loaded, both >>>>> states are already in synch without any calls or toggling. >>>> >>>> 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. >>> >>> 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. >> >> We shouldn't really use the term IRQ as it's confusing. I like the term >> "pin" better because that describes what we're really talking about. >> >> qemu_irq is designed oddly today because is represents something that is >> intrinsically state (whether a pin is high or low) with an edge notification >> with the assumption that the state is held somewhere else (which is usually >> true). >> >> Modelling stateful pins is useful though for doing something like >> introspecting pin levels, supporting live migration, etc. >> >> The way this works in QOM right now is that the Pin object has a level state >> that can be queried but it also has the ability to register for >> notifications on level change. >> >> The edge change signal isn't registered until realize. This means that you >> can connect all of the device models, restore all of the pin states, and >> then realize the device model all at once. At the point of realize, all of >> the devices have the right pin levels so each device can add their edge >> change signals and read the incoming pins and respond accordingly. > > Even if the devices read the input pins on restore, they shouldn't > make any changes to their output pins because that would propagate to > other devices. To handle this in non-chaotic way would need hacks to > each device, multiphase stuff, priorities or transient suppressors. > From the device point of view, restoring is not a state change and no > edges should be seen at that moment. A device wouldn't get a signal about an irq edge at realize. Restoring an arbitrarily complex device model wouldn't result in any irq edge notifications because all of the devices are created and their state is set before any device is realized. Since an edge event only occurs when the state changes of an IRQ after realize, no edge events will happen. Whether a device reads the level of an IRQ during realize though depends on the device. I don't think there's any strong reason to but I also don't think it's fundamentally wrong for a device to read an IRQ level at realize. Regards, Anthony Liguori >