From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41376) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XRdck-00081I-FR for qemu-devel@nongnu.org; Wed, 10 Sep 2014 04:51:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XRdce-0001HL-AL for qemu-devel@nongnu.org; Wed, 10 Sep 2014 04:51:34 -0400 Received: from mail-lb0-f170.google.com ([209.85.217.170]:33146) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XRdce-0001H5-2t for qemu-devel@nongnu.org; Wed, 10 Sep 2014 04:51:28 -0400 Received: by mail-lb0-f170.google.com with SMTP id u10so3839705lbd.15 for ; Wed, 10 Sep 2014 01:51:26 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <54100E16.1040306@redhat.com> References: <1410265809-27247-1-git-send-email-pbonzini@redhat.com> <1410265809-27247-10-git-send-email-pbonzini@redhat.com> <20140909135424.GA13212@redhat.com> <540F35E3.7060207@redhat.com> <20140909205122.GB15637@redhat.com> <54100E16.1040306@redhat.com> From: Peter Maydell Date: Wed, 10 Sep 2014 09:51:06 +0100 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [PATCH 09/10] piix: do not raise irq while loading vmstate List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Juan Quintela , "Michael S. Tsirkin" , QEMU Developers , "Dr. David Alan Gilbert" , Pavel Dovgaluk , Amit Shah On 10 September 2014 09:38, Paolo Bonzini wrote: > Il 09/09/2014 22:51, Michael S. Tsirkin ha scritto: >> Sorry I still don't understand. Why do stuff from vmstate callback then? >> How is it different? > > Reconstructing internal state from post_load is okay. > > What is not okay (and I think it should be a rule) is to touch other > devices from post_load, unless you know that they are deserialized > first. For example it's okay for a PCI device to talk to the parent > bridge in its post_load function. I don't think it's right to talk to another device even if you do know it's deserialized first. Talking to it might make it change its state, which would be wrong (since its correct state is the state it's just deserialized). I would suggest the rule should be "never do something that can change the state of another device in post-load". (We have similar issues with reset, except worse in that we don't have a coherent rule to cause everything to come out of reset in the right state.) thanks -- PMM