From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:45754) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QzwUa-0000QH-Ns for qemu-devel@nongnu.org; Sat, 03 Sep 2011 16:07:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QzwUZ-0005QY-MM for qemu-devel@nongnu.org; Sat, 03 Sep 2011 16:07:04 -0400 Received: from mail-yx0-f173.google.com ([209.85.213.173]:49229) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QzwUZ-0005QT-DK for qemu-devel@nongnu.org; Sat, 03 Sep 2011 16:07:03 -0400 Received: by yxt3 with SMTP id 3so1991680yxt.4 for ; Sat, 03 Sep 2011 13:07:02 -0700 (PDT) Message-ID: <4E6288E4.10805@codemonkey.ws> Date: Sat, 03 Sep 2011 15:07:00 -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> <4E5F1F05.7050704@redhat.com> In-Reply-To: <4E5F1F05.7050704@redhat.com> 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: Avi Kivity Cc: Lucas Meneghel Rodrigues , Marcelo Tosatti , qemu-devel , Blue Swirl , Jan Kiszka , Gerd Hoffmann 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. This is essentially computed state. If we wanted to model a stateless pin, we would need to do something like: struct Serial { uint8_t thr; uint8_t lsr; }; static bool serial_get_irq(Serial *s) { return (s->thr & THRE) | (s->lsr & LSRE); } static void serial_write(Serial *s, uint64_t addr, uint8_t value) { switch (addr) { case THR: bool old_irq = serial_get_irq(s); s->thr = value; if (!old_irq && serial_get_irq(s)) { notify_edge_change(s); } ... } static void serial_init(Serial *s) { register_pin(s, serial_get_irq); } Obviously, this is pretty sucky. This is what we do today but we don't have a way to query irq value which is wrong. You could fix that by adding the get function but that's not terribly fun. A better way: struct Serial { Pin irq; uint8_t thr; uint8_t lsr; }; static void serial_update_irq(Serial *s) { pin_set_level(&s->irq, (s->thr & THRE) | (s->lsr & LSRE)); } static void serial_write(Serial *s) { switch (addr) { case THR: s->thr = value; serial_update_irq(s); ... } This results in much nicer code. The edge handling can be done in generic code which will make things more robust overall. Regards, Anthony Liguori