From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40923) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fOLA8-0002sk-Ow for qemu-devel@nongnu.org; Thu, 31 May 2018 06:50:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fOLA7-0006E2-Ed for qemu-devel@nongnu.org; Thu, 31 May 2018 06:50:32 -0400 Received: from mail-oi0-x243.google.com ([2607:f8b0:4003:c06::243]:37573) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fOLA7-0006DH-5y for qemu-devel@nongnu.org; Thu, 31 May 2018 06:50:31 -0400 Received: by mail-oi0-x243.google.com with SMTP id l22-v6so11375148oib.4 for ; Thu, 31 May 2018 03:50:31 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <20180521140402.23318-1-peter.maydell@linaro.org> <20180521140402.23318-24-peter.maydell@linaro.org> <530bef1b-a143-1566-3089-32629ab250b8@redhat.com> From: Peter Maydell Date: Thu, 31 May 2018 11:50:10 +0100 Message-ID: Content-Type: text/plain; charset="UTF-8" Subject: Re: [Qemu-devel] [PATCH 23/27] hw/core/or-irq: Support more than 16 inputs to an OR gate List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: qemu-arm , =?UTF-8?B?QWxleCBCZW5uw6ll?= , QEMU Developers , "patches@linaro.org" , Richard Henderson On 31 May 2018 at 11:21, Paolo Bonzini wrote: > On 30/05/2018 19:35, Peter Maydell wrote: >> On 30 May 2018 at 17:59, Paolo Bonzini wrote: >>> On 21/05/2018 17:02, Peter Maydell wrote: >>>> On 21 May 2018 at 15:34, Paolo Bonzini wrote: >>>>> Why do the levels have to be migrated at all? It should be enough if >>>>> the IRQ level is either migrated manually, or restored (e.g. in >>>>> post_save callbacks) through other data that is migrated. >>>> This is standard behaviour for devices: they track their >>>> inbound irq/gpio lines, and then that becomes internal state for >>>> them that must be migrated. >>> >>> But or_irq's input are another device's outbound lines, so tracking them >>> should not be necessary. The other device would do it for or_irq. >> >> There's no mechanism in qemu_irq for the destination end to ask >> the source end about its current value. The information flow >> is strictly one-way. > > On postload, the source must call qemu_set_irq and that will cause an > update of the or_irq, won't it? No, calling qemu_set_irq in postload is a bug. (You don't know which order the state of the source and destination devices is restored, so asserting a signal in postload would have different effects depending on whether the destination had already had its state restored or not.) The system design relies on each device keeping track of (and migrating) the state of the input lines it cares about. thanks -- PMM