From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=34411 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Q1eGg-00040B-5N
	for qemu-devel@nongnu.org; Mon, 21 Mar 2011 08:31:31 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <mst@redhat.com>) id 1Q1eGb-0000Kg-IX
	for qemu-devel@nongnu.org; Mon, 21 Mar 2011 08:31:26 -0400
Received: from mx1.redhat.com ([209.132.183.28]:46695)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <mst@redhat.com>) id 1Q1eGb-0000Ka-8q
	for qemu-devel@nongnu.org; Mon, 21 Mar 2011 08:31:25 -0400
Date: Mon, 21 Mar 2011 14:31:11 +0200
From: "Michael S. Tsirkin" <mst@redhat.com>
Message-ID: <20110321123111.GA29012@redhat.com>
References: <cover.1300540833.git.yamahata@valinux.co.jp>
	<533593a679f7c243ddce87c9c3a7c31c6f67acd7.1300540833.git.yamahata@valinux.co.jp>
	<20110321113707.GC27445@redhat.com>
	<20110321121032.GA9998@valinux.co.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20110321121032.GA9998@valinux.co.jp>
Subject: [Qemu-devel] Re: [PATCH v3 3/3] piix_pci: optimize set irq path
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Isaku Yamahata <yamahata@valinux.co.jp>
Cc: qemu-devel@nongnu.org

On Mon, Mar 21, 2011 at 09:10:32PM +0900, Isaku Yamahata wrote:
> On Mon, Mar 21, 2011 at 01:37:07PM +0200, Michael S. Tsirkin wrote:
> > > +static int piix3_post_load(void *opaque, int version_id)
> > > +{
> > > +    PIIX3State *piix3 = opaque;
> > > +    piix3_update_irq_levels(piix3);
> > 
> > Couldn't figure out why would we not want to
> > propagate the interrupts here.
> > Could you explain please?
> > What happens if we do propagate them?
> > Nothing bad, right?
> 
> I wanted to be just conservative.
> If you are brave enough to change the behavior, I'm fine with propagating
> interrupts.
> 
> If we propagate the interrupts, guest OS may see interrupts
> unnecessarily/spuriously injected after load.
> Probably such interrupts doesn't harm OSes, so there is nothing
> bad in theory as you said.
> On the other hand, I hesitated to change the existing behavior because
> it would be very difficult to debug it and to test many OSes.

I expect it won't change the behaviour because the interrupts
are level: at the moment e.g. pci devices already reassert
interrupts on load.

But I agree it better be a separate patch, and needs a lot of testing.

> -- 
> yamahata