From mboxrd@z Thu Jan 1 00:00:00 1970 Received: by 2002:a5d:51d0:0:0:0:0:0 with SMTP id n16csp4535139wrv; Tue, 30 Jul 2019 08:48:21 -0700 (PDT) X-Google-Smtp-Source: APXvYqw1s0jADDuh0DGLQV0l8I67OITry0MPkP3r/YPL5wCi3DAxWHZR/IxrAxKNlHXIeEqH1L00 X-Received: by 2002:a17:906:1596:: with SMTP id k22mr7667675ejd.102.1564501701505; Tue, 30 Jul 2019 08:48:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564501701; cv=none; d=google.com; s=arc-20160816; b=sjZ29dm+PWmXjBdItv775sF1tHZg8VcNNy1v6kbeY3wk4ELFSO3s/Iq/VD6uCtXLJa wiHHwdRnEQd54Rtu0mFjWXRK/IYN11l1DXdq/udVUcZ/9EtIgiFGFQQKmYkkAhtLkuxP qxfyVBTyVkNg8K/038vQ5orUdT1iLDoBp6Lmd2+sCJMs/DZghGgDLkewP8nSI6OvcsZs pz/rBVFZYXHBumdWsOQ/fSt5Z8IUxTHqh7dOko2orJOxugkd/8bk+It5Qxju/CZTY+ah Po2Ezdf/ji1KnFvOuBHSf3M/AzGDBD7dHCrNfykqZ6C5XJWw8eB+zq6IxquiwuqdQnZH oVNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:cc:list-subscribe:list-help:list-post:list-archive :list-unsubscribe:list-id:precedence:subject :content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:to:from:date; bh=k/1MNvSm+lb/E+TR9eipkiJxGSgYHd6fuvqL2DKtLCk=; b=kepV6H3e79JeT7kBiQnD/GpDQ0G+EN+KYikpnuhMf3XfVcjhNR6MB6SwOAUn8GwrYj d5b3+h24ShBbGbqQ2hUz53zAcqVJqQ3w9xEqCTkBoDOacMTPMQJDxDDXJsxqK1+pr4/5 K2/hE2QWng914PDtrQ9RVK3EDeo8MfiztkO3qly/bgjeNeqE6OQAbsiLxLzbY3ZIPudx 23RitWRFY4TbaNJZvGzrqqjvRHlXctbIa67RE1hG+2txelDsMKdGVpD0co/qxMPsHDNl Nq8s6mmXO/9Pjy98nPo9+p9AoO0AsO3LiG3ywWaK7nEI1NX7HQ84kJLLseGf485ZUJwS a2cQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of qemu-arm-bounces+alex.bennee=linaro.org@nongnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom="qemu-arm-bounces+alex.bennee=linaro.org@nongnu.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from lists.gnu.org (lists.gnu.org. [209.51.188.17]) by mx.google.com with ESMTPS id f36si19939271edd.292.2019.07.30.08.48.21 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 30 Jul 2019 08:48:21 -0700 (PDT) Received-SPF: pass (google.com: domain of qemu-arm-bounces+alex.bennee=linaro.org@nongnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; Authentication-Results: mx.google.com; spf=pass (google.com: domain of qemu-arm-bounces+alex.bennee=linaro.org@nongnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom="qemu-arm-bounces+alex.bennee=linaro.org@nongnu.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from localhost ([::1]:34072 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hsUMO-0006Ou-JZ for alex.bennee@linaro.org; Tue, 30 Jul 2019 11:48:20 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:47138) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hsUMI-0006Oo-90 for qemu-arm@nongnu.org; Tue, 30 Jul 2019 11:48:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hsUMF-0006BD-4w for qemu-arm@nongnu.org; Tue, 30 Jul 2019 11:48:14 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37618) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hsUM5-000649-Mb; Tue, 30 Jul 2019 11:48:04 -0400 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id EE83B30BD1CC; Tue, 30 Jul 2019 15:47:58 +0000 (UTC) Received: from gondolin (dhcp-192-232.str.redhat.com [10.33.192.232]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8F83719C5B; Tue, 30 Jul 2019 15:47:28 +0000 (UTC) Date: Tue, 30 Jul 2019 17:47:25 +0200 From: Cornelia Huck To: Damien Hedde Message-ID: <20190730174725.10419dfb.cohuck@redhat.com> In-Reply-To: <34a216b0-0067-8627-599c-6a67622c4bd2@greensocs.com> References: <20190729145654.14644-1-damien.hedde@greensocs.com> <20190729145654.14644-2-damien.hedde@greensocs.com> <20190730154209.2049f10a.cohuck@redhat.com> <20190730155547.7b201f5e.cohuck@redhat.com> <34a216b0-0067-8627-599c-6a67622c4bd2@greensocs.com> Organization: Red Hat GmbH MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.49]); Tue, 30 Jul 2019 15:47:59 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.132.183.28 Subject: Re: [Qemu-arm] [PATCH v3 01/33] Create Resettable QOM interface X-BeenThere: qemu-arm@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Fam Zheng , Peter Maydell , Collin Walling , Dmitry Fleytman , "Michael S. Tsirkin" , Mark Cave-Ayland , QEMU Developers , Gerd Hoffmann , Edgar Iglesias , Hannes Reinecke , Qemu-block , David Hildenbrand , Halil Pasic , Christian Borntraeger , Marcel Apfelbaum , =?UTF-8?B?TWFyYy1BbmRyw6k=?= Lureau , Richard Henderson , Thomas Huth , Eduardo Habkost , Alistair Francis , qemu-s390x , qemu-arm , =?UTF-8?B?Q8OpZHJpYw==?= Le Goater , John Snow , David Gibson , "Daniel P. Berrange" , Mark Burton , qemu-ppc , Paolo Bonzini Errors-To: qemu-arm-bounces+alex.bennee=linaro.org@nongnu.org Sender: "Qemu-arm" X-TUID: GDkgTNCs3yln On Tue, 30 Jul 2019 16:08:59 +0200 Damien Hedde wrote: > On 7/30/19 3:59 PM, Peter Maydell wrote: > > On Tue, 30 Jul 2019 at 14:56, Cornelia Huck wrote: > >> > >> On Tue, 30 Jul 2019 14:44:21 +0100 > >> Peter Maydell wrote: > >> > >>> On Tue, 30 Jul 2019 at 14:42, Cornelia Huck wrote: > >>>> I'm having a hard time figuring out what a 'cold' or a 'warm' reset is > >>>> supposed to be... can you add a definition/guideline somewhere? > >>> > >>> Generally "cold" reset is "power on" and "warm" is "we were already > >>> powered-on, but somebody flipped a reset line somewhere". > >> > >> Ok, that makes sense... my main concern is to distinguish that in a > >> generic way, as it is a generic interface. What about adding something > >> like: > >> > >> "A 'cold' reset means that the object to be reset is initially reset; a 'warm' > >> reset means that the object to be reset has already been initialized." > >> > >> Or is that again too generic? > > > > I think it doesn't quite capture the idea -- an object can have already > > been reset and then get a 'cold' reset: this is like having a powered-on > > machine and then power-cycling it. > > > > The 'warm' reset is the vaguer one, because the specific behaviour > > is somewhat device-dependent (many devices might not have any > > difference from 'cold' reset, for those that do the exact detail > > of what doesn't get reset on warm-reset will vary). But every > > device should have some kind of "as if you power-cycled it" (or > > for QEMU, "go back to the same state as if you just started QEMU on the > > command line"). Our current "reset" method is really cold-reset. Ah ok, that makes sense. > > > > Exactly. In the following patches, I've tried to replace existing reset > calls by cold or warm reset depending on whether: > + it is called through the main system reset -> cold > + it is called during normal life-time -> warm > > But I definitely can add some docs/comments to better explain that. Yes, that would be great; I think I now understand enough for looking at the patches. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C78E5C0650F for ; Tue, 30 Jul 2019 15:49:02 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9E9252089E for ; Tue, 30 Jul 2019 15:49:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9E9252089E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:34080 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hsUN3-00072r-QY for qemu-devel@archiver.kernel.org; Tue, 30 Jul 2019 11:49:01 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:47176) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hsUMN-0006SX-8o for qemu-devel@nongnu.org; Tue, 30 Jul 2019 11:48:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hsUMM-0006K1-66 for qemu-devel@nongnu.org; Tue, 30 Jul 2019 11:48:19 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37618) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hsUM5-000649-Mb; Tue, 30 Jul 2019 11:48:04 -0400 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id EE83B30BD1CC; Tue, 30 Jul 2019 15:47:58 +0000 (UTC) Received: from gondolin (dhcp-192-232.str.redhat.com [10.33.192.232]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8F83719C5B; Tue, 30 Jul 2019 15:47:28 +0000 (UTC) Date: Tue, 30 Jul 2019 17:47:25 +0200 From: Cornelia Huck To: Damien Hedde Message-ID: <20190730174725.10419dfb.cohuck@redhat.com> In-Reply-To: <34a216b0-0067-8627-599c-6a67622c4bd2@greensocs.com> References: <20190729145654.14644-1-damien.hedde@greensocs.com> <20190729145654.14644-2-damien.hedde@greensocs.com> <20190730154209.2049f10a.cohuck@redhat.com> <20190730155547.7b201f5e.cohuck@redhat.com> <34a216b0-0067-8627-599c-6a67622c4bd2@greensocs.com> Organization: Red Hat GmbH MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.49]); Tue, 30 Jul 2019 15:47:59 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.132.183.28 Subject: Re: [Qemu-devel] [PATCH v3 01/33] Create Resettable QOM interface X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Fam Zheng , Peter Maydell , Collin Walling , Dmitry Fleytman , "Michael S. Tsirkin" , Mark Cave-Ayland , QEMU Developers , Gerd Hoffmann , Edgar Iglesias , Hannes Reinecke , Qemu-block , David Hildenbrand , Halil Pasic , Christian Borntraeger , =?UTF-8?B?TWFyYy1BbmRyw6k=?= Lureau , Richard Henderson , Thomas Huth , Eduardo Habkost , Alistair Francis , qemu-s390x , qemu-arm , =?UTF-8?B?Q8OpZHJpYw==?= Le Goater , John Snow , David Gibson , "Daniel P. Berrange" , Mark Burton , qemu-ppc , Paolo Bonzini Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Tue, 30 Jul 2019 16:08:59 +0200 Damien Hedde wrote: > On 7/30/19 3:59 PM, Peter Maydell wrote: > > On Tue, 30 Jul 2019 at 14:56, Cornelia Huck wrote: > >> > >> On Tue, 30 Jul 2019 14:44:21 +0100 > >> Peter Maydell wrote: > >> > >>> On Tue, 30 Jul 2019 at 14:42, Cornelia Huck wrote: > >>>> I'm having a hard time figuring out what a 'cold' or a 'warm' reset is > >>>> supposed to be... can you add a definition/guideline somewhere? > >>> > >>> Generally "cold" reset is "power on" and "warm" is "we were already > >>> powered-on, but somebody flipped a reset line somewhere". > >> > >> Ok, that makes sense... my main concern is to distinguish that in a > >> generic way, as it is a generic interface. What about adding something > >> like: > >> > >> "A 'cold' reset means that the object to be reset is initially reset; a 'warm' > >> reset means that the object to be reset has already been initialized." > >> > >> Or is that again too generic? > > > > I think it doesn't quite capture the idea -- an object can have already > > been reset and then get a 'cold' reset: this is like having a powered-on > > machine and then power-cycling it. > > > > The 'warm' reset is the vaguer one, because the specific behaviour > > is somewhat device-dependent (many devices might not have any > > difference from 'cold' reset, for those that do the exact detail > > of what doesn't get reset on warm-reset will vary). But every > > device should have some kind of "as if you power-cycled it" (or > > for QEMU, "go back to the same state as if you just started QEMU on the > > command line"). Our current "reset" method is really cold-reset. Ah ok, that makes sense. > > > > Exactly. In the following patches, I've tried to replace existing reset > calls by cold or warm reset depending on whether: > + it is called through the main system reset -> cold > + it is called during normal life-time -> warm > > But I definitely can add some docs/comments to better explain that. Yes, that would be great; I think I now understand enough for looking at the patches.