From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42751) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dLW5c-0004Vm-0o for qemu-devel@nongnu.org; Thu, 15 Jun 2017 10:49:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dLW5X-0008Ks-2D for qemu-devel@nongnu.org; Thu, 15 Jun 2017 10:49:40 -0400 Received: from mail-wm0-x243.google.com ([2a00:1450:400c:c09::243]:35894) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dLW5W-0008KX-T6 for qemu-devel@nongnu.org; Thu, 15 Jun 2017 10:49:35 -0400 Received: by mail-wm0-x243.google.com with SMTP id d17so303863wme.3 for ; Thu, 15 Jun 2017 07:49:34 -0700 (PDT) Sender: Paolo Bonzini References: <1488276185-31168-1-git-send-email-fred.konrad@greensocs.com> <1db78209-e426-03b5-9a19-592da96adaee@greensocs.com> From: Paolo Bonzini Message-ID: Date: Thu, 15 Jun 2017 16:49:29 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v3 00/10] Clock framework API. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: KONRAD Frederic , Edgar Iglesias , Mark Burton , QEMU Developers , Alistair Francis , =?UTF-8?Q?C=c3=a9dric_Le_Goater?= On 15/06/2017 16:40, Peter Maydell wrote: > On 14 June 2017 at 12:54, Paolo Bonzini wrote: >> I think the various bindings and rates could be refreshed as devices are >> migrated. This assumes that the device migration order is okay >> according to the clock tree > > Unfortunately we make no guarantees at all about migration order > for devices as far as I'm aware, so devices have to cope regardless. It's device realization order, so there are some guarantees. A board can realize devices in its preferred order (and realization will also bind clocks and set rates IIUC, just like migration), and a qdev bus's children will be visited after the bus owner. > (There's also the possibility of an oddball bit of hardware which > has a clocktree with loops in it.) For these cases there is post_load, I guess. Paolo