qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Andreas Färber" <afaerber@suse.de>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Fu Wei <fu.wei@linaro.org>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Christoffer Dall <christoffer.dall@linaro.org>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: Re: [Qemu-devel] [PATCH 4/6] hw/arm/boot: register cpu reset handlers if using -bios
Date: Wed, 17 Sep 2014 18:40:02 +0200	[thread overview]
Message-ID: <5419B962.7060900@suse.de> (raw)
In-Reply-To: <CAFEAcA-=-d_ao9FoByR_3mW25SVWJ8GVDR1kekBYFML_5Q0Ncw@mail.gmail.com>

Am 17.09.2014 um 18:17 schrieb Peter Maydell:
> On 17 September 2014 08:55, Andreas Färber <afaerber@suse.de> wrote:
>> IIRC each machine is responsible for registering a reset hook that calls
>> - in most cases - cpu_reset().
>>
>> The thing to look out for here is, does any machine already register a
>> reset hook and would reset twice with this patch?
> 
> Probably not -- any such double-reset would already be happening
> if the user passed -kernel.
> 
> So in that sense this patch won't break things, but I wasn't
> sure if it's the right direction to go -- should we be fixing
> all the board and/or SoC models to do the CPU reset instead?
> 
> QOM devices get reset when their bus gets reset, right?
> (so everything on a bus gets reset eventually as part of
> the process that starts when the top level sysbus gets reset).

We avoided that by not using DeviceClass::reset but CPUClass::reset.
It's a question of assuring appropriate reset ordering between CPU and
devices. PowerPC needed a special reset order via hook in (what is now)
MachineClass.

So while I agree that CPU reset registration is not ideal and needs
changing, I am not convinced that we can generally make the change and
hope for the best. I wouldn't mind an incremental transition though,
with arm taking the first step - still leaves the question of exact
direction. If you look at x86, you will find that despite my protest
against this inconsistency, the reset hook registration was moved into
CPU code but none of the other targets changed alongside.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

  reply	other threads:[~2014-09-17 16:54 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-05 15:15 [Qemu-devel] [PATCH 0/6] ARM: -bios/-kernel + DTB boot roundup Ard Biesheuvel
2014-09-05 15:15 ` [Qemu-devel] [PATCH 1/6] hw/arm/virt: Provide flash devices for boot ROMs Ard Biesheuvel
2014-09-09 18:20   ` Peter Maydell
2014-09-10  9:09     ` Ard Biesheuvel
2014-09-10  9:12       ` Peter Maydell
2014-09-10 10:27         ` Ard Biesheuvel
2014-09-05 15:15 ` [Qemu-devel] [PATCH 2/6] hw/arm/boot: return size of loaded DTB from load_dtb() Ard Biesheuvel
2014-09-09 17:57   ` Peter Maydell
2014-09-05 15:15 ` [Qemu-devel] [PATCH 3/6] hw/arm/boot: load device tree to base of DRAM if no -kernel option was passed Ard Biesheuvel
2014-09-09 18:02   ` Peter Maydell
2014-09-05 15:15 ` [Qemu-devel] [PATCH 4/6] hw/arm/boot: register cpu reset handlers if using -bios Ard Biesheuvel
2014-09-09 18:14   ` Peter Maydell
2014-09-17 15:50     ` Ard Biesheuvel
2014-09-17 15:55       ` Andreas Färber
2014-09-17 16:17         ` Peter Maydell
2014-09-17 16:40           ` Andreas Färber [this message]
2014-09-17 16:47             ` Peter Maydell
2014-09-17 17:14               ` Andreas Färber
2014-09-17 22:05                 ` Ard Biesheuvel
2014-09-05 15:15 ` [Qemu-devel] [PATCH 5/6] hw/arm/boot: load DTB as a ROM image Ard Biesheuvel
2014-09-09 18:03   ` Peter Maydell
2014-09-05 15:15 ` [Qemu-devel] [PATCH 6/6] hw/arm/boot: enable DTB support when booting ELF images Ard Biesheuvel
2014-09-05 16:42   ` Ard Biesheuvel
2014-09-09 18:08   ` Peter Maydell
2014-09-09 18:15     ` Ard Biesheuvel
2014-09-09 18:17       ` Peter Maydell
2014-09-09 18:20         ` Ard Biesheuvel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5419B962.7060900@suse.de \
    --to=afaerber@suse.de \
    --cc=ard.biesheuvel@linaro.org \
    --cc=christoffer.dall@linaro.org \
    --cc=fu.wei@linaro.org \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).