From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:56528) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T8ZXY-0008Pq-Tk for qemu-devel@nongnu.org; Mon, 03 Sep 2012 12:30:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T8ZXX-0004WJ-8X for qemu-devel@nongnu.org; Mon, 03 Sep 2012 12:30:20 -0400 Received: from david.siemens.de ([192.35.17.14]:19667) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T8ZXW-0004V1-V4 for qemu-devel@nongnu.org; Mon, 03 Sep 2012 12:30:19 -0400 Message-ID: <5044DB15.4030505@siemens.com> Date: Mon, 03 Sep 2012 18:30:13 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1346640974-30974-1-git-send-email-mmogilvi_qemu@miniinfo.net> <1346640974-30974-6-git-send-email-mmogilvi_qemu@miniinfo.net> <50446D11.5050904@suse.de> <5044C10D.7050600@redhat.com> <87fw6z5d0e.fsf@elfo.mitica> <5044D243.3050506@redhat.com> <5044D2A7.7000609@siemens.com> <5044D36E.3060505@redhat.com> <5044D494.3070304@siemens.com> <5044D78D.1060803@redhat.com> In-Reply-To: <5044D78D.1060803@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v4 5/5] i8259: fix dynamically masking slave IRQs with IMR register List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Paolo Bonzini , "quintela@redhat.com" , Matthew Ogilvie , =?UTF-8?B?QW5kcmVhcyBGw6Q=?= =?UTF-8?B?cmJlcg==?= , "qemu-devel@nongnu.org" On 2012-09-03 18:15, Avi Kivity wrote: > On 09/03/2012 07:02 PM, Jan Kiszka wrote: > >>>>> Looks like the optimal condition is ((s->icw3 & ~s->eclr) != 0) (i.e. >>>>> bit set in icw3 but clear in eclr). >>>> >>>> The standard PC values are optimal: 4 for master, 2 for slave. >>> >>> Can you explain why? I saw that icw3 is always ORed with eclr, so my >>> condition will catch exactly those cases where a change in behaviour >>> occurs, and no more. >> >> The values above are what every user of the PIC cascaded on our targets >> must program to use them. So We will find them in the state once any >> relevant guest code was able to run (e.g. the BIOS). >> > > Suppose the bios has not run yet? Then we must save the 0. Your logic will force us to save in all standard cases (ELCR's bit for IRQ2 must not be set by a guest). So it's not really helpful. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux