All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Maydell <peter.maydell@linaro.org>
To: "Andreas Färber" <afaerber@suse.de>
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 09:47:06 -0700	[thread overview]
Message-ID: <CAFEAcA8y4zJt5WoyaaNUAorGr2jpqhUbocdEpMiAg_HAWndSDQ@mail.gmail.com> (raw)
In-Reply-To: <5419B962.7060900@suse.de>

On 17 September 2014 09:40, Andreas Färber <afaerber@suse.de> wrote:
> 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.

I don't object to taking a pragmatic approach in the ARM code
(eg this patch). I just wanted to know if you had a preferred
direction we should be taking instead (which as you say we
kind of have to do in an incremental way). It sounds like you
don't have anything concrete in mind so maybe we should just
apply this patch.

In general I suspect there are a lot of unresolved issues in
our handling of reset -- it's a complicated area which we
attempt to address in an over-simplistic way at the moment :-(
But there's a pile of other problems on the ARM QEMU todo list
so as long as a change like this isn't actively working against
a transition you're working towards then it will solve the
immediate bug.

thanks
-- PMM

  reply	other threads:[~2014-09-17 16:47 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
2014-09-17 16:47             ` Peter Maydell [this message]
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=CAFEAcA8y4zJt5WoyaaNUAorGr2jpqhUbocdEpMiAg_HAWndSDQ@mail.gmail.com \
    --to=peter.maydell@linaro.org \
    --cc=afaerber@suse.de \
    --cc=ard.biesheuvel@linaro.org \
    --cc=christoffer.dall@linaro.org \
    --cc=fu.wei@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.