From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:38598) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SaUFr-0006rr-PN for qemu-devel@nongnu.org; Fri, 01 Jun 2012 11:59:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SaUFm-0006Jv-SU for qemu-devel@nongnu.org; Fri, 01 Jun 2012 11:59:11 -0400 Received: from thoth.sbs.de ([192.35.17.2]:15531) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SaUFm-0006Jo-IM for qemu-devel@nongnu.org; Fri, 01 Jun 2012 11:59:06 -0400 Message-ID: <4FC8E6C8.6020401@siemens.com> Date: Fri, 01 Jun 2012 17:59:04 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <20120530185150.GA1546@redhat.com> <4FC66FB1.9050306@siemens.com> <20120530193034.GE1551@redhat.com> <4FC681B4.3030807@web.de> <20120530203119.GH1551@redhat.com> <4FC8BB28.8000004@siemens.com> <20120601132745.GA21451@redhat.com> <4FC8CA2D.9060001@siemens.com> <20120601143413.GA22754@redhat.com> <4FC8DC9E.7060105@siemens.com> <20120601153000.GB23768@redhat.com> In-Reply-To: <20120601153000.GB23768@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/2] pci: Add pci_device_get_host_irq List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Alex Williamson , Marcelo Tosatti , qemu-devel , Avi Kivity On 2012-06-01 17:30, Michael S. Tsirkin wrote: > On Fri, Jun 01, 2012 at 05:15:42PM +0200, Jan Kiszka wrote: >> On 2012-06-01 16:34, Michael S. Tsirkin wrote: >>> On Fri, Jun 01, 2012 at 03:57:01PM +0200, Jan Kiszka wrote: >>>> On 2012-06-01 15:27, Michael S. Tsirkin wrote: >>>>> On Fri, Jun 01, 2012 at 02:52:56PM +0200, Jan Kiszka wrote: >>>>>> On 2012-05-30 22:31, Michael S. Tsirkin wrote: >>>>>>>>> So we'll just have PIIX_NUM_PIC_IRQS entries there and use >>>>>>>>> irq_count instead of the pic_levels bitmap. >>>>>>>> >>>>>>>> Just that this affects generic PCI code, not only PIIX-specific things. >>>>>>> >>>>>>> Yes but it's not a problem - pci_bus_irqs sets the map function and nirqs. >>>>>>> >>>>>>>> And that we need to save/restore some irq_count field according to the >>>>>>>> old semantics. >>>>>>> >>>>>>> Well, it's a bug: this is redundant info we should not have exposed it. >>>>>>> >>>>>>> Anyway, let's make the rest work properly and cleanly first, add a FIXME >>>>>>> for now, then we'll find a hack making it work for migration. >>>>>> >>>>>> It remains non-trivial: I got your patch working (a minor init issue), >>>>>> but yet without changing the number of IRQs for PIIX3, so keeping the >>>>>> irq_count semantics for this host bridge. >>>>>> >>>>>> Now I'm facing three possibilities of how to proceed: >>>>> >>>>> They all look OK I think :) Some comments below. >>>>> >>>>>> 1. Give up on the (currently broken) feature to write a vmstate for >>>>>> older QEMU versions. >>>>>> >>>>>> This will allow to declare the irq_count field in vmstate_pcibus >>>>>> unused, and we would have to restore it on vmload step-wise via the >>>>>> PCI devices. It would also allow to change its semantics for PIIX3, >>>>>> mapping directly to PIC IRQs. >>>>> >>>>> I think that's okay too simply because these things are usually >>>>> easy to fix after the fact when the rest of the issues are addressed. >>>> >>>> Don't get what you mean with "fixed". If we fix the vmstate generation >>>> in making it backward-compatible again, we enter option 2. Option 1 is >>>> explicitly about giving this up. >>> >>> What I really mean is I think I see how 2 can be added without much >>> pain. So let's focus on 1 for now and worst case we break migration. >> >> I'd like to avoid planing for this worst case as long as there are also >> statements [1] that this is not acceptable for QEMU in general. It >> doesn't to create a beautiful architecture initially about which we >> already know that it will become more complex than alternatives in the end. > > 1 and 2 are same really except 2 adds a hack for compatibility, no? Yes, 2 would allow us to maintain irq_count in different ways as well, specifically using it calculate shared output IRQ lines before reporting them to the PIC generically. This approach has both a charming and an ugly face. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux