From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51867) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VbC8Z-0003pX-Ld for qemu-devel@nongnu.org; Tue, 29 Oct 2013 12:27:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VbC8T-0000Di-NG for qemu-devel@nongnu.org; Tue, 29 Oct 2013 12:27:23 -0400 Received: from mono.eik.bme.hu ([152.66.115.2]:47660) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VbC8T-0000DM-Bi for qemu-devel@nongnu.org; Tue, 29 Oct 2013 12:27:17 -0400 Date: Tue, 29 Oct 2013 17:27:15 +0100 (CET) From: BALATON Zoltan In-Reply-To: <20131026200024.GA27159@comcast.net> Message-ID: References: <1381416174-5110-1-git-send-email-armbru@redhat.com> <1381416174-5110-9-git-send-email-armbru@redhat.com> <87wqlehfg9.fsf_-_@blackfin.pond.sub.org> <525D3B0E.9040304@redhat.com> <87wqldsfuu.fsf@blackfin.pond.sub.org> <525E7347.2050202@redhat.com> <525EBD6F.3060609@redhat.com> <20131026200024.GA27159@comcast.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [Qemu-devel] fix clearing i8259 IRQ lines (Was: Should the i8259 devices remain no-user?) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Matthew Ogilvie Cc: qemu-devel@nongnu.org, Paolo Bonzini , =?ISO-8859-15?Q?Andreas_F=E4rber?= , Anthony Liguori , Markus Armbruster On Sat, 26 Oct 2013, Matthew Ogilvie wrote: > Although the 8259 (interrupts) model is clearly wrong with respect > to clearing an IRQ request line, only one ancient unimportant guest > (Microport UNIX ca. 1987) seems to care, and there are potentially > significant risks to more important guests if we try to fix it: There's at least one more guest that cares I know about which is less ancient but maybe just as unimportant: OPENSTEP for Mach. But nevertheless it still is a now known bug which just seems to be tolerated by the OS-es that are most commonly run under Qemu. What was not clear to me is how significant are the risks of the fix and if they were considered or the patch was just forgotten without ever getting the thought about merging it. > Risks: The 8254 (timers) model is wrong in various ways, some of > which are hidden by the incorrect 8259 model, and fixing it could > potentially break migration, depending on exact circumstances. > Also, it isn't clear if there are other device models depending > on the incorrect 8259 that would also need to be fixed. I had the impression from previous discussion that the main risk was a potential lost timer interrupt in some circumstances at migration which may affect some guests but it was not clear (to me at least) how big of a risk is this. IMO if other models depend on a bug they are also buggy and should be fixed but I don't know how many models could that affect. > If someone actually showed real interest in actually merging > these, including the selection of a migration compatibility > strategy they would actually be willing to merge (and above: > other devices, KVM, etc), I could look into updating > the patches to match. But the "if" parts aren't looking > particularly likely. This seems like a rather core-level > wide-implication change for a newbie to be messing > with. (I've already spent noticably more time on qemu > patches than I had intended to spend total on playing with > this guest, although I may continue if I have a clearly > defined strategy.) I think you have already provided detailed analysis, test cases and multiple options and patch versions so it is not you who should spend more time on this now. What I think would be needed is that people who have the knowledge and insight to analyse and decide about the patches give it some time to think about it and come to a decision then tell what to do or why it's better to leave it unfixed. Can this be done in this thread? Or maybe on one of the upcoming phone conferences where the right people are together anyway to discuss it? Regards, BALATON Zoltan