From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:42008) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T8ZJ2-00006w-FC for qemu-devel@nongnu.org; Mon, 03 Sep 2012 12:15:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T8ZIw-0008CZ-Oa for qemu-devel@nongnu.org; Mon, 03 Sep 2012 12:15:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:19832) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T8ZIw-0008C3-FK for qemu-devel@nongnu.org; Mon, 03 Sep 2012 12:15:14 -0400 Message-ID: <5044D78D.1060803@redhat.com> Date: Mon, 03 Sep 2012 19:15:09 +0300 From: Avi Kivity 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> In-Reply-To: <5044D494.3070304@siemens.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: Jan Kiszka Cc: Paolo Bonzini , "quintela@redhat.com" , Matthew Ogilvie , =?UTF-8?B?QW5kcmVhcyBGw6Q=?= =?UTF-8?B?cmJlcg==?= , "qemu-devel@nongnu.org" 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? -- error compiling committee.c: too many arguments to function