Re: [Qemu-devel] [PATCH] pc: Clean up PIC-to-APIC IRQ path

From: Jan Kiszka <jan.kiszka@siemens.com>
To: "Edgar E. Iglesias" <edgar.iglesias@gmail.com>
Cc: Lucas Meneghel Rodrigues <lmr@redhat.com>,
	Anthony Liguori <aliguori@us.ibm.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	Blue Swirl <blauwirbel@gmail.com>, Avi Kivity <avi@redhat.com>,
	Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] pc: Clean up PIC-to-APIC IRQ path
Date: Wed, 31 Aug 2011 20:28:38 +0200	[thread overview]
Message-ID: <4E5E7D56.9090907@siemens.com> (raw)
In-Reply-To: <20110831180445.GB17959@zapo>

On 2011-08-31 20:04, Edgar E. Iglesias wrote:
> On Wed, Aug 31, 2011 at 04:59:40PM +0000, Blue Swirl wrote:
>> On Wed, Aug 31, 2011 at 8:28 AM, Avi Kivity <avi@redhat.com> 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.
> 
> I may be missunderstanding something, but I agree with the stateless part.
> Fundamentally changing IRQ lines like this, deviating from how hardware
> normally handles it just to squeeze in other features seems wrong. At
> least until other alternatives have been proved to be impossible, but
> i doubt that is this case here.

Just to clarify: We do not depend on state-full generic IRQ lines to
solve the in-kernel to in-kernel IRQ delivery problem or to cut short
the path for user space device models. But we do need fully explorable
IRQ routes and the ability to lazily update device states that we skip
when delivering via fast path. How that is finally modeled can be
discussed (and has to wait for QOM anyway).

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux