From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:59110) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SaUXv-0000kL-HZ for qemu-devel@nongnu.org; Fri, 01 Jun 2012 12:17:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SaUXp-0003DT-D2 for qemu-devel@nongnu.org; Fri, 01 Jun 2012 12:17:51 -0400 Received: from thoth.sbs.de ([192.35.17.2]:30376) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SaUXp-0003Cx-1t for qemu-devel@nongnu.org; Fri, 01 Jun 2012 12:17:45 -0400 Message-ID: <4FC8EB25.3030207@siemens.com> Date: Fri, 01 Jun 2012 18:17:41 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <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> <20120601152851.GA23768@redhat.com> <4FC8E5A7.2000001@siemens.com> <20120601160533.GC23768@redhat.com> In-Reply-To: <20120601160533.GC23768@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 18:05, Michael S. Tsirkin wrote: > On Fri, Jun 01, 2012 at 05:54:15PM +0200, Jan Kiszka wrote: >> On 2012-06-01 17:28, Michael S. Tsirkin wrote: >>>>> So I won't object to adding a new API but if we do >>>>> it properly this won't help compatibility :( >>>> >>>> It will as this API does not touch the parts that affect the vmstate >>>> (ie. semantics of irq_count won't change). >>> >>> Yes but irq_count in vmstate is a bug. IMO even if we do >>> not change anything we should ignore irq_count on >>> load and recalculate it from what the devices supply. >> >> I don't disagree. But this will only allow keeping backward migration >> support if we preserve the semantics of current map_irq somewhere - to >> keep the chance of calculating the legacy values for vmsave as well. >> >> Jan > > We don't need to preserve it, right? We can calculate it before > savevm. We can't calculate it without something like the additional infrastructure I listed. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux