qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Maydell <peter.maydell@linaro.org>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: "Paolo Bonzini" <pbonzini@redhat.com>,
	"Keith Packard" <keithp@keithp.com>,
	qemu-arm <qemu-arm@nongnu.org>,
	"Alex Bennée" <alex.bennee@linaro.org>,
	"QEMU Developers" <qemu-devel@nongnu.org>
Subject: Re: Semihosting, arm, riscv, ppc and common code
Date: Wed, 15 Jan 2020 13:32:05 +0000	[thread overview]
Message-ID: <CAFEAcA8mphBky9Q2HTdOpQHiizd+5-o=yRnBbd_k1y6Uk-h8dA@mail.gmail.com> (raw)
In-Reply-To: <3ab2ca1f7a9b37b201a58f3a817edc5193e8b1f4.camel@kernel.crashing.org>

On Wed, 15 Jan 2020 at 01:17, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Tue, 2020-01-14 at 09:59 +0000, Peter Maydell wrote:
> > Note that semihosting is not a "here's a handy QEMU feature"
> > thing. It's an architecture-specific API and ABI, which should
> > be defined somewhere in a standard external to QEMU.
>
> There is no such standard for powerpc today that I know of.

So you need to write one down somewhere. You're proposing
an ABI which will be implemented by multiple implementors
and used by multiple consumers. That needs a spec, not
just code. I don't want to see more semihosting implementations
added to QEMU that don't have a specification written
down somewhere.

The riscv single paragraph in their arch spec that vaguely
says "works like arm semihosting" is not sufficient detail, incidentally.

> Keith and I are somewhat of a different mind here. From the perspective
> of the user of that API (picolibc is one), it's easier to deal with a
> single one and have everybody inherit the same bugs.
>
> Now I understand the point of wanting to fix the mistakes made but I
> would suggest we do so by proposing extensions to the existing one to
> do so.

The point about the mistakes is that you can't easily fix
them by adding extensions, because the core of the biggest
mistake is "we didn't provide a good way to allow extensions to
be added and probed for by the user". So we had to implement
an ugly and hard to implement mechanism instead. New
architectures could mandate providing the good way from the start
and avoid the painful-to-implement approach entirely.
(I think RISCV has already missed this window of opportunity,
which is a shame.)

thanks
-- PMM


  reply	other threads:[~2020-01-15 13:33 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-14  6:25 Semihosting, arm, riscv, ppc and common code Benjamin Herrenschmidt
2020-01-14  7:32 ` Liviu Ionescu
2020-01-14  7:53   ` Benjamin Herrenschmidt
2020-01-14  9:51     ` Alex Bennée
2020-01-15  1:14       ` Benjamin Herrenschmidt
2020-01-15 12:01         ` Alex Bennée
2020-01-15 12:30           ` Liviu Ionescu
2020-01-15 21:28           ` Richard Henderson
2020-01-15 22:02             ` Liviu Ionescu
2020-01-16  2:04               ` Benjamin Herrenschmidt
2020-01-16  7:57                 ` Liviu Ionescu
2020-01-16  6:33           ` Benjamin Herrenschmidt
2020-01-14  9:59 ` Peter Maydell
2020-01-15  1:17   ` Benjamin Herrenschmidt
2020-01-15 13:32     ` Peter Maydell [this message]
2020-01-16  2:01       ` Benjamin Herrenschmidt
2020-01-16 11:05         ` Peter Maydell

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='CAFEAcA8mphBky9Q2HTdOpQHiizd+5-o=yRnBbd_k1y6Uk-h8dA@mail.gmail.com' \
    --to=peter.maydell@linaro.org \
    --cc=alex.bennee@linaro.org \
    --cc=benh@kernel.crashing.org \
    --cc=keithp@keithp.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-arm@nongnu.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).