From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:33222) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QzxUM-0007Oe-TN for qemu-devel@nongnu.org; Sat, 03 Sep 2011 17:10:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QzxUL-0005cn-Tu for qemu-devel@nongnu.org; Sat, 03 Sep 2011 17:10:54 -0400 Received: from mail-qw0-f43.google.com ([209.85.216.43]:46815) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QzxUL-0005ch-Nf for qemu-devel@nongnu.org; Sat, 03 Sep 2011 17:10:53 -0400 Received: by qwm42 with SMTP id 42so2836221qwm.30 for ; Sat, 03 Sep 2011 14:10:53 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4E6288E4.10805@codemonkey.ws> References: <4E58FC3F.6080809@web.de> <4E5BE7C5.60705@us.ibm.com> <4E5BFF51.9010503@web.de> <4E5C00F0.9070103@redhat.com> <4E5DF096.6070207@redhat.com> <4E5F1F05.7050704@redhat.com> <4E6288E4.10805@codemonkey.ws> From: Blue Swirl Date: Sat, 3 Sep 2011 21:10:33 +0000 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: Anthony Liguori Cc: Lucas Meneghel Rodrigues , Marcelo Tosatti , qemu-devel , Jan Kiszka , Gerd Hoffmann , Avi Kivity On Sat, Sep 3, 2011 at 8:07 PM, Anthony Liguori wro= te: > On 09/01/2011 12:58 AM, Avi Kivity wrote: >> >> 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. > > In Real Life, you can tie a single bit multiple registers together with > boolean logic to form an output pin. =C2=A0This is essentially computed s= tate. > =C2=A0If we wanted to model a stateless pin, we would need to do somethin= g like: > > struct Serial { > =C2=A0 uint8_t thr; > =C2=A0 uint8_t lsr; > }; > > static bool serial_get_irq(Serial *s) { > =C2=A0 return (s->thr & THRE) | (s->lsr & LSRE); > } > > static void serial_write(Serial *s, uint64_t addr, uint8_t value) > { > =C2=A0 switch (addr) { > =C2=A0 case THR: > =C2=A0 =C2=A0 =C2=A0bool old_irq =3D serial_get_irq(s); > =C2=A0 =C2=A0 =C2=A0s->thr =3D value; > =C2=A0 =C2=A0 =C2=A0if (!old_irq && serial_get_irq(s)) { > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0notify_edge_change(s); > =C2=A0 =C2=A0 =C2=A0} > =C2=A0 ... > } > > static void serial_init(Serial *s) > { > =C2=A0 =C2=A0register_pin(s, serial_get_irq); > } > > Obviously, this is pretty sucky. =C2=A0This is what we do today but we do= n't have > a way to query irq value which is wrong. =C2=A0You could fix that by addi= ng the > get function but that's not terribly fun. =C2=A0A better way: > > struct Serial { > =C2=A0 =C2=A0Pin irq; > =C2=A0 =C2=A0uint8_t thr; > =C2=A0 =C2=A0uint8_t lsr; > }; > > static void serial_update_irq(Serial *s) > { > =C2=A0 pin_set_level(&s->irq, (s->thr & THRE) | (s->lsr & LSRE)); > } > > static void serial_write(Serial *s) { > =C2=A0 switch (addr) { > =C2=A0 case THR: > =C2=A0 =C2=A0 =C2=A0s->thr =3D value; > =C2=A0 =C2=A0 =C2=A0serial_update_irq(s); > =C2=A0 ... > } > > This results in much nicer code. =C2=A0The edge handling can be done in g= eneric > code which will make things more robust overall. I'm sorry but I don't see a huge difference, could you elaborate? Maybe if the internal state of Pin is magically shared between the endpoint devices (like typedef bool *Pin) and the devices somehow still save Pin state as part of their own despite the duplication, this could work. Restoring Pins first and then devices is a sort of priority scheme.